0

当社には専任の DBA は雇用されていませんが、DBA 機能を実行する厳選された開発者がいます。開発サイクル中にデータベースを頻繁に更新し、さまざまな更新を含むリリース スクリプトを用意しています。db スキーマとオブジェクトを Visual Studio のデータベース プロジェクトに保持します。

ただし、多くの場合、時間のかかる手動介入を引き起こす 2 つの障害が発生します。

  • データを含む既存のテーブルに NOT NULL フィールドを追加した場合、データベースへの VS のデプロイ プロセスは「テスト」データだけを自動的に挿入するほどスマートではないため、開発者は常にデータベース プロジェクトからローカル データベースに同期できるとは限りません。フィールドをテーブルに取得します (これがどこかで設定されていない限り?)。もちろん、可能であれば、フィールドに実際のデータを入力するスクリプトを使用してこれをフォローアップしますが、展開が失敗するためできません。

  • 開発者は、過去のランダムな日付からバックアップを復元することがあります。どのデータベース更新がこのデータベースに適用されたかを正確に知る方法がないため、どのスクリプトを適用し始めるかわかりません。この場合、各スクリプトを時系列でチェックして、そのスクリプトからの変更がデータベースに適用されているかどうかを確認します。その場合は、次に実行するスクリプトに進みます。繰り返す。

これまで説明してきた方法の 1 つは、データベースに 1 フィールド、1 行の「データベース更新レベル」テーブルを作成する可能性があることです。データベースが更新されたレベルを維持します。たとえば、最初のスクリプトが実行されるときに、レベルを 2 に更新します。各 db スクリプトでは、次のようなチェックでステートメントをラップします。

IF Database_Update_Level < 2 THEN ここでいくつかのことを行います

UPDATE Database_Update_Level SET Database_Update_Level = 2 END IF

個々のステートメントは特定のレベル以下では実行されないため、db スクリプトは任意のデータベースで実行できます。

これは、開発者がローカルで開発することを許可するすべての開発ショップが遭遇する共通の問題に違いないため、何かが欠けているように感じます。

どんな洞察も大歓迎です。

ありがとう。

4

2 に答える 2

0

NOT NULL 問題を解決する簡単な方法の 1 つは、デフォルトの制約を確立することです (空の文字列、データ型の最大数値、最大日付値など)。パブリッシュが発生すると、新しい列にデフォルト値が入力されます。

2 番目の問題については、SSDT プロジェクトでデプロイ後のスクリプトを使用して、'NOT EXISTS' を使用して増分変更を行い、データの同期を維持します。そうすれば、単純にデータベースを公開して、データの更新を次々と行うことができます。

于 2013-11-15T01:48:57.113 に答える
0

復元の問題については、多くの解決策が見当たりません。完全な復元を回避し、代わりにスクリプトを実行してテーブルにデータを入力することを試みることができます。バージョニング構造に関しては、VS で SSDT (SQL Server Data Tools) を使用していますか? DACPAC を生成し、差分スクリプトを生成できます。

しかし、データベース内の構造も直接変更しているということですか? それを避ける方法はありませんか？そうでない場合は、たとえば DDL トリガー ( http://www.mssqltips.com/sqlservertip/2085/sql-server-ddl-triggers-to-track-all-database-changes/ ) を使用して、少なくとも何かの通知を受け取ることができますかわった。

于 2013-11-14T21:05:12.923 に答える