じゃじゃ馬ならし

データベースを設計しますか？ いいえ、新しいNoSQLではなく、古き良きリレーショナルSQLです。データとロジックにアクセスするための関係とストアドプロシージャを記述することができます。 たぶん、あなたはPostgreSQL用のデータベースを開発していますか？ もしそうなら、素晴らしい-この投稿は間違いなくあなたのためです。



PostgreSQLの利点を説明することは、おそらく意味がありません。 簡単に言えば、それは豊富な機能を備えた最新の高速DBMSであり、商用のデータベース管理システムと競合できるということです。 PostgreSQLがBSD ライセンスと同様の無料ライセンスの下で配布されているという事実（商用プロジェクトで使用料なしで使用でき、変更の際に独自のコードを開かなくてもソースコードへのフルアクセスを提供します）。 、2016年1月、バージョン9.5がリリースされ、いくつかの非常に優れた改善が行われました ）、PostgreSQLはこれまでで最高のDBMSの1つであると主張できます。 しかし、PostgreSQL開発者の間で人気を得ることを妨げるものは何ですか？







これらの要因の1つは、データベース開発とさらなるメンテナンスの両方のためのかなり少数のツールです。 もちろん、PostgreSQL用のJDBCドライバーがあり、JDBCを使用するすべてのツールが動作しますが、これらのツールは通常普遍的であり、特定のDBMSの機能を常に使用できるわけではありません。



どの開発機能について話しているのですか？ たとえば、既存のデータベースオブジェクト（通常はテーブルまたはビュー）を変更すると、PostgreSQLがこれを許可しないため、オブジェクトの変更中にエラーが発生することがよくあります。 依存オブジェクトがあります。

ags=# create table t1 (f1 text); CREATE TABLE ags=# create view v1 as select * from t1; CREATE VIEW ags=# alter table t1 alter column f1 type char(5); ERROR: cannot alter type of a column used by a view or rule : rule _RETURN on view v1 depends on column "f1"
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

同様の機能がすでに多くの開発者を悩ませており、TODO wiki.postgresql.org/wiki/Todo#Views_and_Rulesに記録され、いくつかの可能な解決策があります（例： mwenus.blogspot.nl/2014/04/postgresql-how-to-handle-table-table and-view.html ）。



または、別の例を示します。 これはあなたには起こりませんでした。ストアドプロシージャを作成し、それを積極的に使用し始め、しばらくしてから、通常はそれを修正したかったのです。 そして、ロジックが部分的に機能し、部分的に機能しない理由を理解し始めたときにのみ、実際にはコードの一部で使用される新しい署名を使用して追加のプロシージャを作成し、コードの他の部分は誤って誤って残された古いプロシージャを使用することに気付きますか？

 ags=# \df f1    |  |    |    |  --------+-----+-----------------------+------------------------+--------- public | f1 | void | |  public | f1 | void | p1 integer |  (2 )
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

この状況に直面するのは非常に簡単です。これは、私の意見では、ストアドプロシージャを論理的に結合し、通常「忘れられた」オブジェクトの外観を排除する1つのパッケージでデータベースにロールするOracleパッケージのようなグループ化オブジェクトがないことによって促進されます。 はい、もちろん、コードをテストしている場合、そのようなオブジェクトが戦闘に入る可能性は小さいですが、この動作により追跡の複雑さが増します。



2つのデータベースを比較し、一方を他方に変換するスクリプトを作成する場合はどうすればよいですか？ ほとんどの場合、 Liquibaseを使用することをお勧めしますが、Liquibaseが少し前に述べた依存関係の問題を解決する方法について何も知らないことを知ったとき、あなたは不愉快に腹を立てます。



3年ほど前にMSSQLからPostgreSQLへの移行プロセスを開始したときに、同様の質問に直面しました。 当時、 Redgate SQL Source Controlを使用してMSSQLを操作していましたが、PostgreSQLを操作するための同様のツールがないことに非常に悩まされていました。 彼らは非常に悩まされ、データベースの変更を追跡し、選択されたオブジェクトの移行のスクリプトをインタラクティブモードと自動モードの両方で作成できる独自のツールを作成することにしました。



私たちはほとんどがJavaでプログラミングしているため、開発プラットフォームを選択する決定はすぐに出ました。 Eclipseアドオンのセットとして、試行錯誤を数回繰り返した後、アプリケーションの開発が始まりました。



それが、しばらくして、製品が生まれた方法です-pgCodeKeeper。



つまり、その操作は次のように説明できます。データベースオブジェクトは、Eclipseプロジェクトの形式でディスクに保存され、将来（必要に応じて）バージョンストレージシステムに配置できます。 データベースとプロジェクトまたはプロジェクトブランチのいずれかをさらに比較すると、データベースから（プロジェクトからデータベースにオブジェクトの状態を転送するために）反対方向に移行スクリプトを作成できます。 そして、独自のANTLR文法を使用してオブジェクトを解析するという事実により、これにより、オブジェクトのかなりよく発達した依存関係グラフを構築することができます。これにより、適切な移行スクリプトの作成につながります（上記で表明された依存関係の既存の問題を考慮に入れます）。



pgCodeKeeperを使用すると、データベースに変更を加えるワークフローを構築できます。 私たちは自宅で次のスキームを使用しています。

1. 開発者は、開発データベースに変更を加えます（移行データベースの作成時に必要になる移行スクリプトの作成については考慮しません）。 ところで、複数の開発者間で共有される1つの開発者データベースが存在する場合があります。 変更を適用する場合、pgCodeKeeperでは選択したオブジェクトのみを転送できます。
   
   
2. 開発者がpgCodeKeeperを使用して行った変更（必要に応じて、オブジェクトの一部のみへの変更）がプロジェクトの開発ブランチに転送され、メインブランチとのマージ要求[マージ要求]が作成されます。
   
   
3. 関連付け要求は、責任者によって検証され、受け入れられます。
   
   
4. マージリクエストを受け入れた後、pgCodeKeeperは、メインブランチから戦闘データベースへの移行スクリプト（データ損失につながる可能性のある命令がスクリプトで生成されると警告します）を生成します。
   
   
5. 作成されたスクリプトは、戦闘データベースにロールされます。
   
   

最初の2つのポイントは開発者によって実行され、3番目はインスペクターによって実行され、4番目と5番目はデータベースに同行する人によって実行されます。 4番目と5番目のポイントは自動モードでも実行できます。これは、連続配信プロセス[Continuous Delivery]の構築に非常に便利ですが、現在の記事ではこれについては説明しません。



説明したワークフローでは、すべてのアクションがpgCodeKeeperを介して実行されるわけではありません。 たとえば、バージョン管理システムでの新しいブランチの作成は、Eclipse用のEGitアドオンによって実行されます。 GitLabの機能を使用して、マージリクエストコードレビュー[マージリクエストコードレビュー]を確認します。



つまり pgCodeKeeperの主な目標は、以前に作成されたプロジェクトをデータベースインスタンスと比較し、変更されたオブジェクトを定義し、データベースからプロジェクトに変更（プロジェクトファイルの変更）またはプロジェクトからデータベースに変更を適用することです（移行スクリプトを作成します）。



時間が経ち、プロジェクトが正常に開発を開始し、特定の瞬間に、製品が内部データベースを維持するための現在の要件に対応していることは間違いありませんでしたが、製品のバックログは決して空ではありません。 また、他の開発者のデータベースで発生する可能性のある機能やエラーで満たされています。 プロジェクトは、企業プロジェクトのフレームワーク内にとどまるか（そして、現在要求されている機能がほぼすべて完了しているため、停滞の段階に入る可能性があります）、または公開市場に参入して、フィードバックを使用して次の質問への回答を受け取ることが明らかになりました：

1. 製品は現在、ソフトウェア市場で需要がありますか？
   
   
2. 需要がある場合、製品のどの流通/ライセンスモデルが、私たちと市場の両方にとって最も関心があるのでしょうか？
   
   

これで、使用の唯一の条件であるフィードバックを提供するパブリックベータテストでpgCodeKeeperをリリースする準備ができました。 職場で製品を試してみたい人はいますか？

ビジネスにトライ

ですから、ここまで読んでいただければ、実際にpgCodeKeeperを試してみるのに十分興味があることを願っています。 準備はいい？ 降りる。



前に書いたように、pgCodeKeeperはその進化の道の終わりにEclipseプラットフォームのアドオンのセットになり始めました。 そしてこれは、マルチプラットフォームではすべてが彼と一緒にうまくいくことを意味し、彼はLinuxとWindowsの両方で働いています。 当然、Eclispeプラットフォームを起動できる他のプラットフォームでも機能しますが、これら2つのみを使用します。



pgCodeKeeperが正常に動作するには、EclipseプラットフォームバージョンJuno以降が必要ですが、この注釈は、Eclipseの既存のインスタンスにインストールする場合に適用されます。 新しいEclipseインストールの場合、 eclipse.org / downloadsから最新バージョンを入手してください。 Java開発者向けのEclipse IDEをインストールできます（とりわけ、Gitとの統合のためのアドオンがあり、サイズが比較的小さいため）、または好きなものを選択できます（忘れないでください：EclipseはJavaアプリケーションです、それが機能するためには、まずJRE / JDKをインストールする必要があります）。







メニュー項目[ヘルプ]-[新しいソフトウェアのインストール]を選択し、更新サイトのURL pgcodekeeper.ru/update/releaseを入力します。



pgCodeKeeperアドオンを選択してインストールします。 Eclispeをオーバーロードし、新しいプロジェクトのウィザードのリストにpgCodeKeeperプロジェクトが表示された場合、インストールミッションが完了したと見なします。



pgCodeKeeperの作業は、プロジェクト内のオブジェクトとデータベースの比較に帰着します。プロジェクトの作成時には、プロジェクトの最初の「キャスト」を作成するデータベースがすでにあるはずです。 データベースを作成して、データベース開発プロセスを試してみましょう。





さて、私たちにはデータベースがあります。それでは、少し楽しんで、コードを書きましょう。 テーブルt1を変更します。

 (ags@10.84.0.6:5432) 15:12:28 [dev] =# alter table t1 alter column f1 type char(5); ERROR: cannot alter type of a column used by a view or rule : rule _RETURN on view v1 depends on column "f1" : 2,393 
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

予想される-要求されたアクションを実行できません。 v1の表示はテーブルt1に依存します。 さらに、v1を削除するには、v2とf1の両方を削除する必要があります。

 (ags@10.84.0.6:5432) 15:16:05 [dev] * =# drop view v1; ERROR: cannot drop view v1 because other objects depend on it : view v2 depends on view v1 function f1(integer) depends on type v2 : Use DROP ... CASCADE to drop the dependent objects too. : 1,631 
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

はい...私たちは小さなtrapにあるようです、今私たちは奇跡のスクリプトの助けに頼らなければなりません（たとえば、上で書いたものに似ています...しかし、それらは依存グラフに落ちる可能性のあるすべてのオブジェクトで動作しません）、またはpgCodeKeeper（カスケード方式でビューと依存オブジェクトを削除し、以前に保存したダンプから失われたオブジェクトを復元する別のオプションがありますが、この「機会」は使用しません）。



データベースを管理するプロジェクトを作成するときが来ました。







新しいプロジェクトの名前を入力します。







データベースのソースを設定しています（はい、新しいソースを追加する少し不明瞭な瞬間に遭遇するかもしれませんが、辛抱強く、将来的には間違いなく改善します）。 私は通常、パスワードを.pgpassに保存し、pgCodeKeeperがパスワードを取得できますが、使用しない場合は、ウィザードのパスワードフィールドに入力します。







プロジェクトの作成が完了したら、「完了」ボタンをクリックします。 すべてを正しく実行すると、新しいプロジェクトが初期化され、データベースオブジェクトが入力されます。







プロジェクト内のデータベースオブジェクトは、人間が読み取れるファイルであり、編集することもできます。







現在、pgCodeKeeperは本格的なSQLまたはPL / pgSQLコードエディタとして位置付けられていませんが、たとえば、この場合のように、エディタで直接ファイルを編集するよりも優れている場合があります。 単一フィールドのタイプをテキストからchar（5）に変更しましょう。







プロジェクトのメインパネル（下部のタブは[データベースの更新]）に移動し、[変更を取得]ボタンをクリックします。 pgCodeKeeperは、データベースとプロジェクトの両方で異なるオブジェクトのリストを表示しました。 差分パネルには、データベースオブジェクトの詳細な変更が表示されます。







さて、これで少し残ったので、プロジェクトオブジェクトと同期させたいデータベースオブジェクトにチェックを入れ、[スクリプトの生成]ボタンをクリックします。 pgCodeKeeperは、生成されたスクリプトに、データの損失につながる可能性のある危険な指示が含まれていることを有益に報告し、次のスクリプトを生成します。





やったー！ マウスを数回クリックするだけで（プロジェクトの初期化を除く）、移行スクリプトを作成できます！ 結果のスクリプトは、pgAdmin / psqlとpgCodeKeeperの両方で独立してロールできます。 PostgreSQLではDDL命令がトランザクション対応であるため、このようなスクリプトをロールオーバーする場合、スクリプトの実行中にエラーが発生した場合にデータベースの一貫性のない状態が発生しないように、1つのトランザクション（psqlでは-1キー）でスクリプトを実行する必要があることを示します。



ここでプロジェクトとデータベースの比較を繰り返すと、プロジェクトとデータベースのオブジェクトが異なることがわかります...！



パニックが発生しないのは、プロジェクトに手動で変更を加えたときに、タイプ文字の短縮形をcharとして示したが、現在はデータベースに完全な形で表示されているためです。







プロジェクトを更新するには、下部のタブ「プロジェクトの更新」に切り替え、「変更を取得」をクリックし、必要なオブジェクトを選択して「選択した変更を適用」ボタンをクリックします。 これらのアクションを実行すると、データベースとプロジェクトオブジェクトは同一になります。

有名な製品の特徴

この製品は元々内部データベース用に開発されたため、使用するオブジェクトのタイプのみが最初にテストされ、一部はまだサポートされていません（たとえば、FOREIGN TABLE）。 pgCodeKeeperはPostgreSQLのすべてのバージョンでの動作をサポートしていません。現在、バージョン9.3以降で動作することが保証されています（確認する必要があります-9.1-9.2では動作しますが、それ以前では動作しません）。

おわりに

今日、PostgreSQLとの連携を容易にする新製品に出会い、次のようなトピックに触れることなく製品の主な機能について話しました：依存関係の手動追加（パーサーが失敗した場合、いつでも伝えることができます）、バージョン管理システムの操作、pgCodeKeeperの動作自動の非対話型モード。



この記事は、新語、専門用語、またはいくつかの時代遅れのスピーチのフレーズなしでは実現しませんでした。すべての場合、単語または表現の意味を、最初の使用時に英語で最も正確に定義しました。



現在、pgCodeKeeperは、2015年11月16日のロシア連邦政府令1236「国家および地方自治体のニーズを満たすための調達を目的とした外国からのソフトウェアの入国禁止の確立について」に従って、国内ソフトウェアのレジストリで登録プロセスを行っています。 garant.ru/hotlaw/federal/671898これは、近い将来、pgCodeKeeperが輸入代替プログラムに参加できることを意味します。



pgCodeKeeperを使用すると、PostgreSQLデータベースのメンテナンスが大幅に容易になります（中毒性の影響も確認されています）。



pgCodeKeeperはどのようにおもしろいと思いましたか？