現在、データベースのマスターddlを作成しています。これまで、バックアップ/復元を使用してデータベースをバージョン管理し、ddlスクリプトを維持していませんでした。スキーマはかなり大きいです。
私の現在の考え：
スクリプトをいくつかの部分に分割します（おそらく別々のスクリプトで）：
各スクリプトは、マスタースクリプトによって呼び出されます。
他に何かアドバイスはありますか？
編集：また、プロセスの一部を自動化するための優れたツールを知っている人がいる場合は、MS SQL 2000を使用しています（古い、私は知っています）。
基本的な考え方は良いと思います。
最初にすべてのテーブルを作成してからすべての制約を作成する利点は、テーブルを任意の順序で作成できることです。これを行うと、テーブルごとに 1 つのファイルがあり、それを「Tables」というディレクトリに置き、そのディレクトリ内のすべてのファイルを実行するスクリプトを作成しました。同様に、テーブルが構築された後に実行される制約スクリプト (外部キーとインデックスも実行) 用のフォルダーがありました。
トリガーとストアド プロシージャのビルドを分離し、これらを最後に実行します。これらのポイントは、データに影響を与えることなく、データベースで実行および再実行できることです。つまり、通常のコードと同じように扱うことができます。各トリガーおよびプロシージャ スクリプトの先頭に「if exists...drop」ステートメントを含めて、それらを再実行できるようにする必要があります。
したがって、順序は次のようになります
それで
現在のプロジェクトでは、MSBuild を使用してスクリプトを実行しています。SQLスクリプトを呼び出すことができるようにするために取得できる拡張ターゲットがいくつかあります。過去に、私は perl も使用しましたが、これも問題ありませんでした (バッチ ファイルはお勧めしませんが、制限が多すぎます)。
あなたが持っているものはかなり良いようです。私の会社では、データベースが十分に大きい場合、それをさらに細かく分類して、おそらく個々のオブジェクトレベルに分類することがあります。このようにして、各テーブル/インデックス/...には独自のファイルがあります。役に立つこともあれば、やり過ぎになることもあります。本当にあなたがそれをどのように使っているかに依存します。
@ジャスティン
ほとんどの場合、ドメイン別で十分です。私は、このようにそれを行うときに対処するいくつかの複雑さがあることに同意しますが、それは処理するのに十分簡単でなければなりません。
この方法は、それ自体をかなり扱いやすくしながら、もう少し分離を提供すると思います（大規模なデータベースではそれを理解するようになります）。また、これらのDDLファイルの多くの処理を行うPerlスクリプトを作成するので、それを処理するための良い方法のオプションになる可能性があります。
時間をかけて一般的な「すべての制約を削除」スクリプトを作成するので、それを維持する必要はありません。
次のステートメントの上にカーソルを置くと、うまくいきます。
Select * From Information_Schema.Table_Constraints
Select * From Information_Schema.Referential_Constraints
@アダム
または、ドメインごとにどうでしょうか。同じファイル内の関連するテーブルの便利なグループですが、残りのテーブルとは別になっていますか？
唯一の問題は、一部のドメイン（このややレガシーなシステム）が緊密に結合されているかどうかです。さらに、異なるサブスクリプト間の依存関係を維持する必要があります。
SQL サーバー全体を反復処理し、すべてのテーブル、ビュー、格納された手順、および UDF 定義をローカル ファイル システムに SQL スクリプト (テキスト ファイル) として抽出する優れたツールがあります。私はこれを 2005 年と 2008 年で使用しましたが、2000 年でどのように機能するかはわかりません。http://www.antipodeansoftware.com/Home/Productsをご覧ください
自動化ツールを探している場合、データベースから ddl スクリプトを自動的に生成できる EMS SQLManager を使用することがよくあります。
データベースをオンラインにする前に、参照テーブルへのデータ挿入が必須になる場合があります。これは、ddl スクリプトの一部と見なすこともできます。EMS は、既存のデータベースからデータ挿入用のスクリプトを生成することもできます。
インデックスの必要性は、ddl 段階で適切に見積もられない場合があります。主キー/外部キーに対してそれらを宣言するだけです。ビューとクエリが定義されたら、後で他のインデックスを作成する必要があります
以前、エンティティごとに 1 つのファイルで編成された DDL コードを整理し、これを 1 つの DDL スクリプトに結合するツールを作成しました。
私の前の雇用主は、すべてのテーブル DDL を 1 つのファイル (オラクル構文で格納) に、インデックスを別のファイルに、制約を 3 番目に、静的データを 4 番目に格納する方式を使用していました。変更スクリプトは、これと並行して保持されました (これも Oracle で)。SQL への変換は手動でした。めちゃくちゃでした。私は実際に、Oracle DDL を SQL Server に変換する便利なツールを作成しました (99.9% の確率で機能しました)。
最近、データベース プロフェッショナル向けの Visual Studio Team System の使用に切り替えました。これまでのところ問題なく動作していますが、データベース内で CLR 関数を使用すると、いくつかの問題が発生します。