データベース項目にソース管理を使用していますか？[閉まっている]

データベーススキーマの変更をバージョン管理するための確実なプロセスがないため、ショップに穴が開いているように感じます。私たちは多くのバックアップを行っているため、多かれ少なかれカバーされていますが、この方法で最後の防御線に依存することは悪い習慣です。

驚いたことに、これは一般的なスレッドのようです。データベースは頻繁に変更されないため、この問題を無視するように私が話した多くの店は、基本的に細心の注意を払うようにしています。

しかし、私はその話がどうなるか知っています。物事がうまくいかず、何かがなくなってしまうのは時間の問題です。

このためのベストプラクティスはありますか？あなたのために働いたいくつかの戦略は何ですか？

バージョン管理下でデータベースを取得する必要があります。K.スコットアレンによる一連の投稿を確認してください。

バージョン管理に関して言えば、データベースは多くの場合、二級または三級の市民です。私が見てきたことから、100万年以内にバージョン管理なしでコードを書くことを決して考えないチームは、当然のことながら、アプリケーションが依存する重要なデータベースのバージョン管理の必要性にまったく気づかない可能性があります。データベースが他のコードと厳密に同じ厳密なレベルのソース管理下にない場合に、ソフトウェアエンジニアと自分を呼んでまっすぐな顔を保つ方法はわかりません。これをあなたに起こさせないでください。データベースをバージョン管理下に置いてください。

データベース自体？番号

それらを作成するスクリプト（静的データ挿入、ストアドプロシージャなどを含む）。もちろん。これらはテキストファイルであり、プロジェクトに含まれており、他のすべてと同様にチェックインおよびチェックアウトされます。

もちろん、理想的な世界では、データベース管理ツールがこれを実行します。しかし、あなたはそれについて訓練されなければなりません。

Rails ActiveRecordの移行が大好きです。DMLをRubyスクリプトに抽象化して、ソースリポジトリで簡単にバージョン管理できるようにします。

ただし、少しの作業で、同じことを行うことができます。DDLの変更（ALTER TABLEなど）はテキストファイルに保存できます。ファイル名の番号付けシステム（または日付スタンプ）を保持し、それらを順番に適用します。

Railsには、最後に適用された移行を追跡する「バージョン」テーブルもDBにあります。簡単に同じことができます。

ソース管理を使用してデータベースの変更を管理するためのLiquiBaseを確認してください。

ログインして「ALTER TABLE」コマンドの入力を開始し、本番データベースを変更しないでください。私が取り組んでいるプロジェクトにはすべての顧客サイトにデータベースがあり、データベースへのすべての変更は2つの場所で行われます。新しい顧客サイトで新しいデータベースを作成するために使用されるダンプファイルと、実行される更新ファイルです。現在のデータベースのバージョン番号をファイル内の最大番号と照合して更新し、データベースを適切に更新します。たとえば、最後の2つの更新：

if [ $VERSION \< '8.0.108' ] ; then
  psql -U cosuser $dbName << EOF8.0.108
    BEGIN TRANSACTION;
    --
    -- Remove foreign key that shouldn't have been there.
    -- PCR:35665
    --
    ALTER TABLE     migratorjobitems
    DROP CONSTRAINT migratorjobitems_destcmaid_fkey;
    -- 
    -- Increment the version
    UPDATE          sys_info
    SET             value = '8.0.108'
    WHERE           key = 'DB VERSION';
    END TRANSACTION;
EOF8.0.108
fi

if [ $VERSION \< '8.0.109' ] ; then
  psql -U cosuser $dbName << EOF8.0.109
    BEGIN TRANSACTION;
    --
    -- I missed a couple of cases when I changed the legacy playlist
    -- from reporting showplaylistidnum to playlistidnum
    --
    ALTER TABLE     featureidrequestkdcs
    DROP CONSTRAINT featureidrequestkdcs_cosfeatureid_fkey;
    ALTER TABLE     featureidrequestkdcs
    ADD CONSTRAINT  featureidrequestkdcs_cosfeatureid_fkey
    FOREIGN KEY     (cosfeatureid)
    REFERENCES      playlist(playlistidnum)
    ON DELETE       CASCADE;
    --
    ALTER TABLE     ticket_system_ids
    DROP CONSTRAINT ticket_system_ids_showplaylistidnum_fkey;
    ALTER TABLE     ticket_system_ids
    RENAME          showplaylistidnum
    TO              playlistidnum;
    ALTER TABLE     ticket_system_ids
    ADD CONSTRAINT  ticket_system_ids_playlistidnum_fkey
    FOREIGN KEY     (playlistidnum)
    REFERENCES      playlist(playlistidnum)
    ON DELETE       CASCADE;
    -- 
    -- Increment the version
    UPDATE          sys_info
    SET             value = '8.0.109'
    WHERE           key = 'DB VERSION';
    END TRANSACTION;
EOF8.0.109
fi

これを行うにはもっと良い方法があると確信していますが、これまでのところうまくいきました。

はい。コードはコードです。私の経験則では、開発マシンや本番マシンを見ることなく、アプリケーションをゼロからビルドおよびデプロイできる必要があります。

私が見たベストプラクティスは、ステージングサーバーでデータベースをスクラップして再構築するビルドスクリプトを作成することです。各イテレーションにはデータベースの変更用のフォルダーが与えられ、すべての変更は "Drop ... Create"でスクリプト化されました。このようにして、バージョンを付けたいフォルダーにビルドをポイントすることで、いつでも以前のバージョンにロールバックできます。

これはNaNt / CruiseControlで行われたと思います。

はい、データベースをバージョン管理することが重要だと思います。データではなく、スキーマです。

Ruby On Railsでは、これは「マイグレーション」を伴うフレームワークによって処理されます。dbを変更するときはいつでも、変更を適用するスクリプトを作成し、それをソース管理にチェックインします。

私のショップはそのアイデアをとても気に入ったので、シェルスクリプトとAnt を使用してJavaベースのビルドに機能を追加しました。プロセスを展開ルーチンに統合しました。DBのバージョニングを標準でサポートしていない他のフレームワークで同じことを行うスクリプトを書くのはかなり簡単です。

Visual Studioの新しいデータベースプロジェクトは、ソース管理と変更スクリプトを提供します。

彼らは、データベースを比較し、一方のスキーマを他方に変換するスクリプトを生成したり、一方のデータを他方に一致するように更新したりできる優れたツールを備えています。

DBスキーマは「細断処理」されて、DBを記述するDDLコマンドごとに1つずつ、多数の小さな.sqlファイルが作成されます。

+ tom

追加情報2008-11-30

私は過去1年間、開発者として使用しており、本当に気に入っています。開発作業と本番環境を簡単に比較し、リリースに使用するスクリプトを生成できます。DBAが「エンタープライズタイプ」のプロジェクトに必要な機能が欠落しているかどうかはわかりません。

スキーマはSQLファイルに「細断」されるため、ソース管理は正常に機能します。

1つの落とし穴は、dbプロジェクトを使用するときに異なる考え方を持つ必要があることです。このツールには、VSに「dbプロジェクト」があり、これは単なるsqlであり、さらに、スキーマと他の管理データを含む自動生成されたローカルデータベースがあります。ただし、アプリケーションデータはなく、使用するローカルdev dbアプリデータ開発作業。自動的に生成されたdbに気づくことはめったにありませんが、それをそのままにしておけるように、そこにあることを知っておく必要があります。この特別なdbは、その名前にGuidがあるため、明確に認識できます。

VS DBプロジェクトは、他のチームメンバーが行ったデータベースの変更をローカルプロジェクト/関連するデータベースに統合するという素晴らしい仕事をします。ただし、プロジェクトスキーマをローカルのdev dbスキーマと比較してmodを適用するには、追加の手順を実行する必要があります。それは理にかなっていますが、最初は扱いにくいようです。

DBプロジェクトは非常に強力なツールです。スクリプトを生成するだけでなく、すぐに適用できます。それを使用して本番データベースを破壊しないようにしてください。;）

私はVS DBプロジェクトが本当に好きで、今後のすべてのdbプロジェクトでこのツールを使用することを期待しています。

+ tom

SQLデータベースのソース管理システムを使用することを開発チームに要求することは、問題の発生を防ぐ魔法の弾丸ではありません。開発者はオブジェクトに加えた変更を別のSQLスクリプトに保存し、ソース管理システムクライアントを開き、クライアントを使用してSQLスクリプトファイルをチェックインする必要があるため、データベースソース管理自体が追加のオーバーヘッドをもたらします。変更をライブデータベースに適用します。

ApexSQL Source Controlと呼ばれるSSMSアドインの使用を提案できます。開発者は、SSMSから直接ウィザードを使用して、データベースオブジェクトをソース管理システムに簡単にマッピングできます。アドインには、TFS、Git、Subversion、およびその他のSCシステムのサポートが含まれています。また、静的データを制御するソースのサポートも含まれています。

ApexSQLソース管理をダウンロードしてインストールしたら、バージョン管理するデータベースを右クリックし、SSMSのApexSQLソース管理サブメニューに移動します。[データベースをソース管理にリンク]オプションをクリックし、ソース管理システムと開発モデルを選択します。その後、選択したソース管理システムのログイン情報とリポジトリ文字列を提供する必要があります。

詳細については、この記事をご覧ください。http：//solutioncenter.apexsql.com/sql-source-control-reduce-database-development-time/

作成/更新スクリプトとsampledataを生成するスクリプトを保存することで実行します。

はい、SQLをビルドの一部として保持することでこれを行います。DROP.sql、CREATE.sql、USERS.sql、VALUES.sqlを保持し、これらをバージョン管理するため、タグ付きバージョンに戻すことができます。

必要なときにいつでもdbを再作成できるantタスクもあります。

さらに、SQLは、それに付随するソースコードとともにタグ付けされます。

私がこれまでプロジェクトで使用した中で最も成功したスキームは、バックアップと差分SQLファイルを組み合わせたものです。基本的に、すべてのリリース後にデータベースのバックアップを取り、SQLダンプを実行して、必要に応じて空のスキーマを最初から作成できるようにしました。次に、DBを変更する必要があるときはいつでも、バージョン管理下のsqlディレクトリにalter scripを追加します。最初の変更は01_add_created_on_column.sqlのようになり、次のスクリプトは02_added_customers_indexになるため、常にファイル名の前にシーケンス番号または日付を付けます。私たちのCIマシンはこれらをチェックし、バックアップから復元されたデータベースの新しいコピーで順次実行します。

また、開発者が1つのコマンドでローカルデータベースを現在のバージョンに再初期化するために使用できるスクリプトもいくつか用意しました。

データベースで作成したすべてのオブジェクトをソース管理します。また、開発者を正直に保つために（オブジェクトをソース管理に入れなくてもオブジェクトを作成できるため）、dbasは定期的にソース管理にないものを探し、見つかった場合は、問題がないかどうかを尋ねずにドロップします。

SchemaBankを使用して、データベーススキーマのすべての変更をバージョン管理しています。

• 1日目から、dbスキーマダンプをインポートします
• Webブラウザーを使用してスキーマ設計を変更し始めました（SaaS /クラウドベースであるため）
• データベースサーバーを更新する場合は、変更（SQL）スクリプトを生成してデータベースに適用します。Schemabankでは、更新スクリプトを生成する前に、バージョンとして作業をコミットするように要求されます。私はこの種の練習が好きなので、いつでも必要なときにさかのぼることができます。

私たちのチームのルールは、最初に設計作業を保存せずに、dbサーバーに直接触れないことです。しかし、それは起こります。誰かが便利のためにルールを破るように誘惑されるかもしれません。スキーマダンプを再度schemabankにインポートし、不一致が見つかった場合は差分を作成して誰かをbashします。そこから変更スクリプトを生成して、dbとスキーマの設計を同期させることはできますが、それは嫌いです。

ちなみに、バージョン管理ツリー内にブランチを作成して、ステージング用と本番用に1つずつ維持できるようにすることもできます。サンドボックスのコーディング用。

バージョン管理と変更管理を備えた、非常にきちんとしたWebベースのスキーマ設計ツール。

データそのものを除いて、ベアメタルからDBを再作成するために必要なすべてのものを持っています。実行する方法はたくさんあると思いますが、すべてのスクリプトなどはsubversionに格納されており、subversionからすべてを取り出してインストーラーを実行することで、DB構造などを再構築できます。

私は通常、変更ごとにSQLスクリプトを作成し、別の変更ではそれらの変更を元に戻し、それらのスクリプトをバージョン管理下に置いています。

次に、オンデマンドで新しい最新のデータベースを作成する手段があり、リビジョン間を簡単に移動できます。リリースを行うたびに、スクリプトをまとめます（少し手作業が必要ですが、実際に難しいことはめったにありません）。したがって、バージョン間で変換できるスクリプトのセットもあります。

はい、言うまでもなく、これはRailsや他の人がすることと非常によく似ていますが、かなりうまく機能しているように見えるので、恥ずかしがらずにアイデアを持ち上げたことを認めても問題ありません:)

私は、MySQL WorkbechからエクスポートされたSQL CREATEスクリプトを使用してから、それらの「Export SQL ALTER」機能を使用して、一連の作成スクリプト（もちろん番号が付けられています）とそれらの間の変更を適用できる変更スクリプトを作成します。

3.-エクスポートSQL ALTERスクリプト通常、モデルに加えた変更を反映して、ALTER TABLEステートメントを手動で作成する必要があります。しかし、あなたは賢く、Workbenchにあなたのためのハードワークを任せることができます。メインメニューから[ファイル]-> [エクスポート]-> [フォワードエンジニアSQL ALTERスクリプト…]を選択するだけです。

これにより、現在のモデルと比較する必要があるSQL CREATEファイルを指定するように求められます。

手順1のSQL CREATEスクリプトを選択します。ツールによってALTER TABLEスクリプトが生成され、データベースに対してこのスクリプトを実行して、スクリプトを最新の状態にできます。

これは、MySQLクエリブラウザーまたはmysqlクライアントを使用して行うことができます。モデルとデータベースが同期されました！

ソース：MySQL Workbench Community Edition：スキーマ同期のガイド

もちろん、このスクリプトはすべてバージョン管理下にあります。

はい、いつも。必要なときにいつでも、有用なサンプルデータのセットを使用して運用データベース構造を再作成できるはずです。そうしないと、時間をかけて物事を実行し続けるためのマイナーな変更が忘れられてしまい、ある日、かまれて大きな時間がかかります。あなたはあなたがあなたが必要とは思わないかもしれないその保険ですが、あなたがそれをする日はそれが10倍以上の価格の価値があります！

データベースモデル自体については多くの議論がありましたが、必要なデータは.SQLファイルにも保持しています。

たとえば、アプリケーションを有効にするために、インストールでこれが必要になる場合があります。

INSERT INTO Currency (CurrencyCode, CurrencyName) 
VALUES ('AUD', 'Australian Dollars');

INSERT INTO Currency (CurrencyCode, CurrencyName) 
VALUES ('USD', 'US Dollars');

currency.sqlsubversionの下に呼ばれるファイルがあるでしょう。ビルドプロセスの手動ステップとして、以前のcurrency.sqlを最新のものと比較し、アップグレードスクリプトを記述します。

データベースを取り巻くすべてをバージョン管理およびソース管理します。

• DDL（作成および変更）
• DML（参照データ、コードなど）
• データモデルの変更（ERwinまたはER / Studioを使用）
• データベース構成の変更（権限、セキュリティオブジェクト、一般的な構成の変更）

これらすべてを、Change Managerといくつかのカスタムスクリプトを使用した自動化ジョブで実行します。Change Managerがこれらの変更を監視し、完了したら通知します。

すべてのDBはソース管理下にある必要があり、開発者はローカルデータベースを最初から作成する簡単な方法を持つ必要があると思います。Visual Studio for Database Professionalsに触発されて、MS SQLデータベースをスクリプト化するオープンソースツールを作成し、それらをローカルDBエンジンに簡単にデプロイできる方法を提供します。http://dbsourcetools.codeplex.com/を試してください。楽しんでください-ネイサン。

データベースがSQL Serverである場合、私たちはあなたが探しているソリューションだけを持っているかもしれません。SQLソース管理1.0がリリースされました。

http://www.red-gate.com/products/SQL_Source_Control/index.htm

これはSSMSに統合され、データベースオブジェクトとVCSの間の接着剤を提供します。「スクリプト出力」は透過的に行われ（内部ではSQL Compareエンジンを使用します）、そのため、開発者がプロ​​セスを採用することを思いとどまらないほど簡単に使用できます。

代替のVisual StudioソリューションはReadyRollで、SSDTデータベースプロジェクトのサブタイプとして実装されます。これには、移行主導のアプローチが採用されています。これは、DevOpsチームの自動化要件により適しています。

すべてのオブジェクト（テーブル定義、インデックス、ストアドプロシージャなど）をスクリプト化して、データベーススキーマをソース管理します。ただし、データ自体については、定期的なバックアップに依存するだけです。これにより、すべての構造変更が適切な改訂履歴で確実にキャプチャされますが、データが変更されるたびにデータベースに負担がかかることはありません。

私たちのビジネスでは、データベース変更スクリプトを使用しています。スクリプトを実行すると、その名前がデータベースに保存され、その行が削除されない限り、再度実行されることはありません。スクリプトは、日付、時刻、コードブランチに基づいて名前が付けられているため、制御された実行が可能です。

ライブ環境でスクリプトが実行される前に、多くのテストが行​​われるため、 "oopsoop"は通常、開発データベースでのみ発生します。

現在、すべてのデータベースをソース管理に移行中です。sqlcompareを使用してデータベース（残念ながら、プロフェッショナル版の機能）をスクリプト化し、その結果をSVNに入れています。

実装の成功は、組織の文化と実践に大きく依存します。ここの人々は、アプリケーションごとにデータベースを作成すると信じています。ほとんどのアプリケーションで使用される共通のデータベースセットがあり、データベース間の依存関係が多数発生しています（一部は循環型です）。私たちのシステムにはデータベース間の依存関係があるため、データベーススキーマをソース管理に配置することは非常に困難です。

幸運をお祈りします。問題を解決するまでの時間を早めに試してください。

ThoughtWorksのhttp://dbdeploy.com/にあるdbdeployツールを使用しました。移行スクリプトの使用を奨励します。各リリースでは、理解を容易にし、DBAが変更を「祝福」できるように、変更スクリプトを1つのファイルに統合しました。

これは常に私にとっても大きな不快感でした。開発データベースにすばやく変更を加えて保存（変更スクリプトの保存を忘れ）すると、行き詰まってしまうのは簡単すぎるようです。変更したスクリプトを元に戻し、やり直して変更スクリプトを作成することもできます。もちろん、スクリプトの作成に多くの時間を費やしていますが、必要に応じて最初から作成することもできます。

これを手助けしてくれた過去に使ったツールはSQL Deltaです。2つのデータベース（SQLサーバー/オラクル）の違いを示し、A-> Bの移行に必要なすべての変更スクリプトを生成します。もう1つの優れた点は、本番（またはテスト）DBと開発DBの間のデータベースコンテンツの違いをすべて表示することです。アプリの実行に不可欠な構成と状態をデータベーステーブルに保存するアプリが増えるにつれ、適切な行を削除、追加、変更する変更スクリプトを作成するのは非常に困難になります。SQL Deltaは、Diffツールで表示されるのと同じように、変更、追加、削除されたデータベース内の行を表示します。

優れたツール。ここにリンクがあります：http : //www.sqldelta.com/

RedGateは素晴らしいです。データベースが変更されると小さなスナップショット（小さなバイナリファイル）を生成し、そのファイルをプロジェクトとしてリソースとして保持します。データベースを更新する必要があるときはいつでも、RedGateのツールキットを使用してデータベースを更新し、空のデータベースから新しいデータベースを作成することもできます。

RedGateはデータのスナップショットも作成しますが、私は個人的にはそれらを使用していませんが、同じくらい堅牢です。

参考までに、これは数日前にDanaによって提唱されました... ソース管理のストアドプロシージャ/ DBスキーマ