0

次のようなテーブルがあるとしましょう。

CREATE TABLE Foo
(
    Id INT IDENTITY NOT NULL PRIMARY KEY,
    Data VARCHAR(10) NOT NULL,
    TimeStamp DATETIME NOT NULL DEFAULT GETUTCDATE()
);

ここで、これを SQL Server データベース プロジェクトで構築し、アプリケーションのバージョン 1.0 で公開するとします。アプリケーションがデプロイされ、テーブルが期待どおりに使用されます。

1.1 リリースでは、製品所有者はデータのソースを追跡することを決定し、これは今後必須の列になります。データベースに既に存在するデータの場合、Data列が数値の場合は、 Source「NUMBER」にする必要があります。そうでない場合は、「UNKNOWN」である必要があります。

データベース プロジェクトのテーブルは次のようになります。

CREATE TABLE Foo
(
    Id INT IDENTITY NOT NULL PRIMARY KEY,
    Data VARCHAR(10) NOT NULL,
    Source VARCHAR(10) NOT NULL,
    TimeStamp DATETIME NOT NULL DEFAULT GETUTCDATE(),
);

これで問題なくビルドできますが、アップグレードをデプロイすると問題が発生します。データがテーブルに存在する場合、これは壊れます。生成されたスクリプトは、一時テーブルを作成し、古いテーブルから一時テーブルにデータを移動し、古いテーブルを削除し、一時テーブルの名前を元の名前に変更します...しかし、そのテーブルにデータがある場合はそうしません。 null 非許容の列に値を割り当てることはできませんSource。

些細なリファクタリングの場合、リファクタリング ログはスキーマの変更を追跡し、変更されたデータベース オブジェクトの認識を維持しますが、少し手を汚すとこれを行う方法がないようです。

データベース プロジェクトをどのように活用して、この変更の既定のスクリプトをアップグレード ロジックを適切にキャプチャするカスタム スクリプトに置き換えることができますか? この問題に対処する何らかの方法があるはずです。

4

0 に答える 0