この記事の目的は、ライブラリの例を使用することです。 スキーマキーパー PostgreSQL DBMS を使用して PHP プロジェクト内でデータベースを開発するプロセスを大幅に簡素化できるツールを示します。

この記事の情報は、まず、PostgreSQL の機能を最大限に活用したいと考えているものの、データベースに配置されたビジネス ロジックの維持に問題を抱えている開発者にとって役立ちます。

この記事では、ビジネス ロジックをデータベースに保存することの利点と欠点については説明しません。 選択は読者によってすでに行われているものと想定されます。

次の質問が検討されます。

1. データベース構造ダンプはどのような形式でバージョン管理システム (以下、VCS と呼びます) に保存されるべきですか?
2. ダンプを保存した後にデータベース構造の変更を追跡する方法
3. 競合や巨大な移行ファイルを発生させずに、データベース構造の変更を他の環境に転送する方法
4. 複数の開発者によるプロジェクトの並行作業のプロセスを整理する方法
5. データベース構造のさらなる変更を実稼働環境に安全にデプロイする方法
   

   スキーマキーパー 言語で書かれたストアド プロシージャを操作するように設計されています PL/pgSQL。 他の言語でのテストは行われていないため、効果が発揮されない、または使用できない可能性があります。

VCS にデータベース構造ダンプを保存する方法

図書館 スキーマキーパー 機能を提供します saveDumpこれにより、データベースのすべてのオブジェクトの構造が個別のテキスト ファイルとして保存されます。 出力はデータベース構造を含むディレクトリであり、VCS に簡単に追加できるグループ化されたファイルに分割されます。

いくつかの例を使用して、オブジェクトをデータベースからファイルに変換する方法を見てみましょう。

オブジェクトタイプ
スキーム
名前
ファイルへの相対パス

テーブル
公共
アカウントの視聴者データを取得する
./public/tables/accounts.txt

ストアドプロシージャ
公共
認証(ハッシュbigint)
./public/functions/auth(int8).sql

はじめに
予約
関税
./booking/views/tariffs.txt

ファイルの内容は、特定のデータベース オブジェクトの構造をテキストで表現したものです。 たとえば、ストアド プロシージャの場合、ファイルの内容は、ブロックで始まるストアド プロシージャの完全な定義になります。 CREATE OR REPLACE FUNCTION.

上の表からわかるように、ファイルへのパスには、オブジェクトのタイプ、スキーマ、名前に関する情報が保存されます。 このアプローチにより、データベース内の変更のダンプとコード レビューを簡単にナビゲートできるようになります。

拡張 .sql ストアド プロシージャ ソース コードを含むファイルの場合、ファイルを開いたときに IDE がデータベースと対話するためのツールを自動的に提供するように、これが選択されています。

ダンプを保存した後にデータベース構造の変更を追跡する方法

現在のデータベース構造のダンプを VCS に保存すると、ダンプの作成後にデータベース構造に変更が加えられたかどうかを確認できます。 図書館内 スキーマキーパー データベース構造の変化を検知する機能を提供 verifyDump、副作用なしで違いに関する情報を返します。

チェックする別の方法は、関数を再度呼び出すことです saveDump、同じディレクトリを指定し、VCS で変更をチェックインします。 データベースのすべてのオブジェクトは別のファイルに保存されるため、VCS には変更されたオブジェクトのみが表示されます。
この方法の主な欠点は、変更を確認するためにファイルを上書きする必要があることです。

競合や巨大な移行ファイルを発生させずに、データベース構造の変更を他の環境に転送する方法

機能のおかげで deployDump ストアド プロシージャのソース コードは、通常のアプリケーションのソース コードとまったく同じ方法で編集できます。 ストアド プロシージャ コードに新しい行を追加/削除して、変更をすぐにバージョン管理にプッシュしたり、ダンプ ディレクトリ内の対応するファイルを作成/削除してストアド プロシージャを作成/削除したりできます。

たとえば、スキーマに新しいストアド プロシージャを作成するには public 拡張子が付いた新しいファイルを作成するだけです .sql ディレクトリ内で public/functions、ブロックを含むストアド プロシージャのソース コードをその中に配置します。 CREATE OR REPLACE FUNCTION、次に関数を呼び出します deployDump。 ストアド プロシージャの変更と削除も同様に行われます。 したがって、コードは VCS とデータベースの両方に同時に入力されます。

ストアド プロシージャのソース コードにエラーが発生した場合、またはファイル名とストアド プロシージャの名前が一致しない場合は、 deployDump は失敗し、エラー テキストが表示されます。 を使用する場合、ダンプと現在のデータベースの間でストアド プロシージャの不一致は発生しません。 deployDump.

新しいストアド プロシージャを作成する場合、正しいファイル名を手動で入力する必要はありません。 ファイルには拡張子があれば十分です .sql。 電話の後 deployDump エラー テキストには正しい名前が含まれており、ファイルの名前を変更するために使用できます。

deployDump これを使用すると、追加の操作を行わずに関数のパラメーターや戻り値の型を変更できますが、従来のアプローチでは次の操作を行う必要があります。
最初に実行する DROP FUNCTION、しかしその時だけ CREATE OR REPLACE FUNCTION.

残念ながら、次のような状況がいくつかあります。 deployDump 変更を自動的に適用できません。 たとえば、少なくとも XNUMX つのトリガーで使用されているトリガー関数が削除された場合です。 このような状況は、移行ファイルを使用して手動で解決します。

ストアド プロシージャへの変更の移行を担当している場合 スキーマキーパーの場合、移行ファイルを使用して構造内の他の変更を転送する必要があります。 たとえば、移行を扱うための優れたライブラリは次のとおりです。 教義/移民.

移行は起動前に適用する必要がある deployDump。 これにより、構造にすべての変更を加えて問題のある状況を解決できるため、ストアド プロシージャの変更はその後問題なく転送されます。

移行の操作については、次のセクションで詳しく説明します。

複数の開発者によるプロジェクトの並行作業のプロセスを整理する方法

データベースを完全に初期化するためのスクリプトを作成する必要があります。このスクリプトは開発者が作業マシン上で起動し、ローカル データベースの構造を VCS に保存されたダンプに準拠させます。 最も簡単な方法は、ローカル データベースの初期化を 3 つのステップに分割することです。

1. という基本構造を持つファイルをインポートします。 base.sql
2. 移行の適用
3. 挑戦 deployDump

base.sql 移行が適用され実行される開始点です deployDumpつまり、 base.sql + миграции + deployDump = актуальная структура БД。 ユーティリティを使用してこのようなファイルを作成できます pg_dump。 使用済み base.sql データベースを最初から初期化する場合のみ。

データベースを完全に初期化するスクリプトを呼び出してみましょう refresh.sh。 ワークフローは次のようになります。

1. 開発者が自分の環境で起動する refresh.sh 現在のデータベース構造を取得します
2. 開発者は当面のタスクの作業を開始し、新しい機能のニーズを満たすようにローカル データベースを変更します (ALTER TABLE ... ADD COLUMN 等）
3. タスクが完了したら、開発者は関数を呼び出します。 saveDumpVCS のデータベースに加えられた変更をコミットするには
4. 開発者の再起動 refresh.sh、その後 verifyDump移行に含める変更のリストが表示されます。
5. 開発者はすべての構造変更を移行ファイルに転送し、再度実行します。 refresh.sh и verifyDumpそして、移行が正しくコンパイルされていれば、 verifyDump ローカルデータベースと保存されたダンプの間に違いは表示されません

上で説明したプロセスは、gitflow の原則と互換性があります。 VCS 内の各ブランチには独自のバージョンのダンプが含まれており、ブランチをマージするとダンプもマージされます。 ほとんどの場合、マージ後に追加のアクションを実行する必要はありませんが、異なるブランチで (たとえば、同じテーブルに対して) 変更が行われた場合、競合が発生する可能性があります。

例を使用して競合状況を考えてみましょう。分岐がある場合 開発する、そこから XNUMX つの枝が分岐します。 feature1 и feature2と矛盾はありません 開発する、しかし、お互いに衝突します。 タスクは、両方のブランチをマージすることです。 開発する。 この場合、最初にブランチの XNUMX つをマージすることをお勧めします。 開発するそしてマージします 開発する 残りのブランチに接続し、残りのブランチの競合を解決してから、最後のブランチをマージします。 開発する。 競合解決フェーズでは、マージの結果を含む最終ダンプと一致するように、最後のブランチの移行ファイルを修正する必要がある場合があります。

データベース構造のさらなる変更を実稼働環境に安全にデプロイする方法

VCS には現在のデータベース構造のダンプが存在するため、運用データベースが必要な構造に正確に準拠しているかどうかをチェックすることが可能になります。 これにより、開発者が意図したすべての変更が実稼働ベースに正常に転送されることが保証されます。

として DDL PostgreSQLでは トランザクション的な、予期しないエラーが発生した場合に「問題なく」実行できるように、次の展開順序に従うことをお勧めします。 ROLLBACK:

1. トランザクションの開始
2. すべての移行をトランザクションで実行する
3. 同じトランザクション内で実行します。 deployDump
4. トランザクションを完了せずに実行する verifyDump。 エラーがなければ実行します COMMIT。 エラーがある場合は実行します ROLLBACK

これらの手順は、ゼロダウンタイムを含め、アプリケーション展開への既存のアプローチに簡単に統合できます。

まとめ

上記の方法により、すべてのビジネス ロジックをメイン アプリケーション コードに実装する場合と比較して、開発の利便性を比較的ほとんど犠牲にせずに、「PHP + PostgreSQL」プロジェクトのパフォーマンスを最大限に引き出すことができます。 また、データ処理においては、 PL/pgSQL 多くの場合、PHP で記述された同じ機能よりも透明性が高く、必要なコードが少なくなります。

出所： habr.com