我们说我有一张这样的桌子:
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
。
对于简单的重构,重构日志跟踪模式中的更改,并保持对已修改的数据库对象的了解,但是当您的手稍微脏一点时,似乎并不是这样做的方法。 / p>
如何利用数据库项目将此更改的默认脚本替换为正确捕获升级逻辑的自定义脚本?必须有一些方法来解决这个问题。