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'。如果不是，它应该是“未知”。

数据库项目中的表现在如下所示：

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(),
);

这构建得很好，但部署升级将是一个问题。如果表中存在数据，这将中断。生成的脚本将创建一个临时表，将旧表中的数据移动到临时表中，删除旧表，并将临时表重命名为原始名称......但如果该表中有数据，则不会，因为它将无法将值分配给不可为空的列Source。

对于微不足道的重构，重构日志会跟踪架构中的更改，并保持对修改后的数据库对象的感知，但是当您手头有点脏时，似乎没有办法做到这一点。

如何利用数据库项目将这一更改的默认脚本替换为正确捕获升级逻辑的自定义脚本？必须有某种方法来解决这个问题。

4

0 回答 0