データベース構造とソース管理-ベストプラクティス
背景
私は、すべてのデータベースオブジェクトがオブジェクトごとに1つのファイルがソース管理に格納されている会社で数年働いていました。新しいアイテムが追加されたときに維持されるすべてのオブジェクトのリストがあり（スクリプトを順番に実行して依存関係を処理できるようにするため）、1つの大きなスクリプトを作成するために実行されたVBスクリプトデータベースに対して実行するため。
すべてのテーブルは「存在しない場合は作成」され、すべてのSPなどは削除および再作成されました。
現在まで、私はデータベースがマスターであり、DBオブジェクトのソース管理がない場所で作業していますが、本番データベースを更新するためにredgateのツールを使用しています（SQL比較）。これは非常に便利です。少しの作業が必要です。
質問
DBオブジェクトをどのように処理しますか？私はそれらをソース管理下に置いておきたい（そして、GITを使用しているので、DBではなくスクリプトでマージの競合を処理できるようにしたい）が、先に進むことを迫られようとしているSQLの使いやすさの比較により、データベースを更新します。
GITでスクリプトを更新してから、SQL比較を使用してDEV DBから本番データベースを更新したくありません。「真実の1つのバージョン」が欲しいのですが、本当にしたくありません。たくさんのスクリプトをまとめてバンドルするために、カスタムのソフトウェアを書き直します。
ビジュアルスタジオデータベースエディションはこれと似たようなことをするかもしれないと思いますが、そのための予算があるかどうかはわかりません。
これは確実に死を求められたと思いますが、私が探している答えがかなりあると思われるものは何も見つかりません。これに似ていますが、まったく同じではありません：
コード制御下のデータベーススクリプトのベストプラクティスは何ですか
私はもう少し意見を求めることに興味があるので、賞金を始めました-ここでの答えは確かですが、もっと簡単な方法があるはずだと思います。
すべての素晴らしい回答に感謝します。すべてにメリットがあるので、私は最高の投票をしますが、すべてのインプットを応援します。
Visual Studio Database Edition（DBPro）を使用して、すべてのデータベースオブジェクトをソース管理しています。これは、スキーマをバージョン管理し、ビルド、検証を行い、コード分析、スキーマ比較、デプロイメント、データ比較、リファクタリングなどを可能にする優れたツールです。DB管理およびバージョン管理システムになるようにゼロから設計されました。強くお勧めします。
これは、DBProの主任アーキテクトのブログサイトです。 ここをクリック
データベースのバージョン管理の原理と実践に関するこの5つのパートシリーズ（K.スコットアレンによる）をご覧ください。
5つの部分は重要ですが、基本的には、ベースラインを作成してから、スクリプト（バージョンテーブルを使用）を変更するという考え方です。データベースの更新とは、現在のバージョンより「上位」の変更スクリプトを適用することを意味します。そして、この戦略は非常にVCSに対応しています（競合はありません）。
サードパーティのSSMSアドイン ApexSQL Source Control を使用すると、データベースオブジェクトを自動的にスクリプト化して、リモートGitリポジトリ、またはローカルリポジトリで作業したい場合は、クローンされたローカルリポジトリにプッシュすることもできます。
ApexSQLソース管理は、そのままGitソース管理システムをサポートします。つまり、追加のGitクライアントをインストールする必要はありません。これに加えて、分岐とマージが統合されており、アドインUIから利用できます。
.netフレームワークを使用していると仮定して、プロジェクトについて説明する Fluent Migrator と Hearding Code Podcast を確認してください。
私が見ている主な目的は、データベースにとらわれないアプローチを使用した流暢なインターフェイスを使用して通常のコーディングを行うときに、移行を簡単にコーディングすることです。
.netフレームワークの上に構築されています。 SQL Server、SqlLite、MySQLなど、さまざまなデータベース形式で動作します。
このアプローチの利点は、コードの残りの部分と共存できるため、SCMで管理できることです。
例：
[Migration(1)]
public class CreateProjectsTable : Migration
{
public void Up()
{
Create.Table("Projects")
.WithIdColumn()
.WithColumn("Name").AsString().NotNullable()
.WithColumn("Position").AsInt32().NotNullable()
.WithColumn("Done").AsBoolean().NotNullable();
}
public void Down()
{
Database.RemoveTable("Projects");
}
}
Red Gateツールを既に使用している場合は、SQLソースコントロールを使用することを検討してください。SQLソースコントロールは、SQL比較およびSQLデータ比較と並行して機能し、ソース管理に1つのバージョンの真実を存在させることができます。現時点では早期アクセスですが、ほとんどの機能が試用できるようになっています。これは http://www.red-gate.com/Products/SQL_Source_Control/index.htm からダウンロードできます。ただし、現時点ではSVNとTFSのみをサポートしています。 GITで標準化しましたか？
David（Red Gateのプロダクトマネージャー）
データベースが名目上ソース管理システム内のマスターであるシステムがあります。一連の「スキーマ変更」スクリプト（.sqlファイル）を維持します。それぞれのスクリプトは、べき等の方法で変更をロールバックして適用します。各スクリプトには番号が付けられているだけなので、000.sql（データベースを作成して標準オブジェクトを設定）、001.sqlなどがあります。
開発中、開発者はスキーマ変更スクリプトを作成し、それを開発データベースに対して実行します。 dba.change_infoテーブルに変更番号と簡単な説明を含む行を追加するには、各変更が必要です。変更をロールバックするには、最初のセクションを実行するだけです。 SQL Serverの場合、ロールバックセクションのべき等は、DROPコマンドを発行する前にsysobjectsなどを調べることによって処理されます。 "drop ... if exists"構成に似ています。スキーマの変更は、モデルが単に追加されるのではなく変更され、参照データを維持するためにも使用される場合、データの移行を行う必要がある場合があります。
リリースプロセス中に、DBA（私たちは小さな会社なので、これはいずれにしても開発者の1人が引き受ける役割です）は、古いバージョンのアプリケーションの停止と開始の間に、リリースのスキーマ変更を本番データベースに適用します更新されたもの。
これはすべて手作業のプロセスですが、モデル間でデータを移行するなどの要件を満たしています。ブールフラグをオプションのセットに拡張する、または多対1の関連付けを多対多に変換する。これは通常、とにかく単純なスキーマ比較ツールで生成できるものではありません。また、役割を分離することもできます。実際には、すべての人が本番環境に完全にアクセスできますが、そこに十分な分離があるため、「DBA」は本番環境に適用される.sqlファイルを読み取って確認できます。
理論的には、少なくとも000.sql以降のすべてのスキーマ変更を実行するだけで、完全なデータベース（参照データのみを含む）を構築できます。実際には、これを定期的に行うのではなく、本番データベースをdevにコピーしてから、変更スクリプトを適用してから、リリース前に回帰テストを実行します。これは変更スクリプト自体をテストするのに役立ちますが、中規模の本番データベースでのみ実用的です。
私はRedGateツールキットにあまり詳しくありませんが、 dbGhost に似ている場合は、データベースオブジェクトをオブジェクトごとに1つずつファイルにスクリプトできるユーティリティが必要です。この場合、次のことをお勧めします。
- [〜＃〜] dev [〜＃〜]データベースをリバースエンジニアリングして毎日の（またはビルドの一部）ジョブをディレクトリ構造に追加する
- 次に、それを（単純なdiffを使用して）リポジトリにあるものと比較し、基本的に[〜＃〜] fail [〜＃〜]ビルド仕事をして、もしあれば
diffを報告してください。これは、DEVデータベースの構造が変更され、ソース管理に反映されていないことを示します。 - これは、変更をソース管理に追加するよう開発者に指示します（これには、報告された
.diffファイルを使用することもできます）
多数のDEVデータベース（ユーザーごとまたは開発ブランチごとに1つ）があり、扱いにくい場合は、データベースのSTAGE（リリース直前のテスト）バージョンでこのようなタスクを実行することをお勧めします。この時点で、PRODスキーマをリポジトリに保存し、リリース前のテスト段階でのみSTAGEからスキーマを更新します。この段階では、スキーマの変更もリポジトリに確実に反映されます。
このようにして、開発者は通常の方法で作業を続けることができます。最初にDEVデータベースのスキーマを変更します。うまくいけば、flexibilityとone truthのバランスが取れます。
私のチームでは、DEVデータベースを変更するとすぐにVCSに変更を追加しますが、異なるデータベース（DEV、STAGE、PROD）間でスキーマを比較するタスクはまだあります。基本的に、私はかつて私がかつて答えたものに従います ソース管理からデータベースをどのように構築すべきですか？ 。
職場では、 ActiveRecord （ Rails Webフレームワークは Migrations と呼ばれます。
基本的な移行は次のようになります。
class AddSystems < ActiveRecord::Migration
def self.up
create_table :systems do |t|
t.string :name
t.string :label
t.text :value
t.string :type
t.integer :position, :default => 1
t.timestamps
end
end
def self.down
drop_table :systems
end
end
データベースが変更されるたびに作成される移行があり、それらはタイムスタンプによって順番に作成されます。事前定義されたメソッドを実行して、これらの移行を適切な順序で実行できるため、データベースを常に作成またはロールバックできます。機能の一部を以下に示します。
rake db:migrate #run all outstanding migrations
rake db:rollback #roll back the last run migration
rake db:seed #fill the database with your seed data
移行には、テーブルの作成、テーブルの削除、テーブルの更新、インデックスの追加などの方法があります。完全なスイート。移行では、id列も自動的に追加され、t.timestampsセクションは、「created_at」フィールドと「updated_at」フィールドを自動的に生成します。
ほとんどの言語にはこのようなORM機能があり、データベースをコードのような状態で維持できるため、開発者が理解しやすく、DBAが使用および維持するのに十分なほど単純です。
この正確なことのための特別なツールがあります。それは Wizardby と呼ばれます：
...データベースの継続的統合とスキーマ移行フレームワーク
私は現在、モデリングツール（DeZine for Databases）でデータベース設計を維持し、それをソース管理下に保存しています。テーブルデザイン内に、スキーマと参照データのバージョン番号を含む2行のテーブルを追加します。これは、データベースが変更またはリリースされるたびに更新されます（ユーザーはこのテーブルにアクセスしません）。
参照データはExcelスプレッドシートで管理され（これもソース管理下にあります）、新しいデータベースにデータを追加するためのINSERTステートメントのSQLスクリプトを生成できます。
新しいリリースが必要な場合、スキーマスクリプト、参照データスクリプト、およびインストーラーパッケージが送信されます。インストーラーパッケージは、古いデータベースの名前を変更し、スクリプトから新しいデータベースを作成し、新しい参照データ（変更されている可能性があります）をインポートします。次に、ユーザーのデータが古い（名前が変更された）データベースから新しいデータベースにコピーされます。
これには、問題が発生したときに、変更されていない元のデータベースに戻すことができるという利点があります。