【发布时间】：2010-07-14 11:58:39
【问题描述】：
在产品版本之间维护升级脚本的最佳方式是什么？如果客户从您产品的第 3 版开始并升级到第 5 版，那么为客户生成升级脚本以解决第 3 版和第 5 版之间数据库架构中的任何差异的最佳方法是什么？
【问题讨论】：
【发布时间】：2010-07-14 11:58:39
【问题描述】：
【讨论】：
-
SQL Compare 过去对我们有很大帮助。我同意，这是比较架构的好方法。
这个之前已经讨论过很多次了：
How to automatically upgrade deployed database for end-users
Database Deployment Strategies (SQL Server)
Any SQL Server 2008 Database Change Management (MIgrations) Tools Available?
Migrator.net 似乎是这些问题中的首选方法。我确实喜欢这种方法，但如果您的情况很简单，您可能更愿意存储 SQL 以在具有版本号的表中执行更改，如下所示：
create table upgradetable (major int, minor int, revision int, change text)
然后你可以通过一个简单的脚本来执行升级：
select change from upgradetable where major > (select major from versiontable)
（当然要根据口味调整）。
如果您无法通过 SQL 进行所有升级，这将不起作用，在这种情况下，我推荐 migrator.net
【讨论】：
我认为这完全取决于您的数据库结构和新版本的新功能。如果新版本与旧版本有很大不同，您可能希望有一个ETL 进程来进行升级，而不仅仅是 SQL 脚本
【讨论】：
可以通过遵循类似于 dbdeploy 或 ruby rake 迁移的方法来处理版本控制。您按顺序对每个更新脚本进行编号，并在数据库中有一个表来存储所有已实施的脚本编号。
升级工具只是应用数量高于数据库中已实现的数量的脚本。
阅读更多here。
【讨论】：
其实很简单。
与在标准代码存储库上进行分支类似，您正在寻找的是一种源代码控制策略，它允许您执行以下操作：
一个。在特定点创建数据库结构的分支。 (v3 / v4)。
湾。使用该分支将数据库恢复到特定版本。 （即 v3 或 v4）。
C。创建一组补丁脚本以从 v3 迁移到 v4，或从 v3 迁移到 v5。
d。在运送给您的客户之前测试这些补丁。
通过这种方式，您可以支持数据库的多个版本，并提供经过测试的升级路径。
看看 DBSourceTools (http://dbsourcetools.codeplex.com)，尤其是补丁策略。
此工具可让您在特定点为数据库设置基线，并创建命名版本 (v1)。
然后，创建一个部署目标 - 并将命名版本增加到 v2。
最后，将补丁脚本添加到 Patches 目录以对架构或数据进行任何更改。
这为您提供了一个可重复的过程来测试要从 v1 应用到 v2 的所有补丁。
DBSourceTools 还具有帮助您创建这些脚本的功能，即模式比较或脚本数据工具。
完成后，只需将补丁目录中的所有文件发送到您的客户端即可。
玩得开心。
【讨论】：