数据库源代码控制与架构更改脚本答案

【问题标题】：Database source control vs. schema change scripts数据库源代码控制与架构更改脚本
【发布时间】：2015-05-12 23:04:07
【问题描述】：

构建和维护一个数据库，然后由许多开发人员进一步部署/开发是软件开发中一直在进行的事情。我们创建一个构建脚本，并维护随着数据库随时间增长而应用的进一步更新脚本。有很多方法可以管理这一点，从手动更新到帮助自动化这些过程的控制台应用程序/构建脚本。

是否有人已经构建/管理了这些流程，并转移到了用于数据库模式管理的源代码控制解决方案？如果是这样，他们找到了最佳解决方案是什么？有什么需要避免的陷阱吗？

Red Gate 似乎是 MSSQL 世界的重要参与者，他们的数据库源代码控制看起来非常有趣： http://www.red-gate.com/products/solutions_for_sql/database_version_control.htm

虽然它看起来不像替换（默认）数据*管理流程，但它只替换了我 pov 中一半的变更管理流程。

（当我谈论数据时，我指的是查找值之类的东西，需要在默认情况下或在 DR 场景中部署的数据）

我们在 .Net/MSSQL 环境中工作，但我确信所有语言的前提都是相同的。

【问题讨论】：

关于 SQL 源代码控制中的静态数据故事，您是对的。但是，该工具的下一个版本中会引入此功能，甚至可能会在今年年底之前推出测试版，供那些注册抢先体验计划 (surveymk.com/s/SqlSourceControl_EapSignup) 的人使用。

【解决方案1】：

这些现有问题中的一个或多个可能会有所帮助：

【讨论】：

【解决方案2】：

我负责管理由我工作的银行内部开发的数据仓库。这需要不断更新，我们有一个由 2-4 名开发人员组成的团队致力于此。

我们很幸运，因为我们的“产品”只有一个实例，因此我们不必迎合部署到可能处于不同版本的多个实例。

我们为数据库中的每个对象（表、视图、索引、存储过程、触发器）保留一个创建脚本文件。

我们尽可能避免使用ALTER TABLE，而是更喜欢重命名表、创建新表并迁移数据。这意味着我们不必查看ALTER 脚本的历史记录——我们总是可以通过查看每个表的创建脚本来查看其最新版本。迁移由单独的迁移脚本执行 - 这可以部分自动生成。

每次发布时，我们都会有一个脚本以适当的顺序运行创建脚本/迁移脚本。

仅供参考：我们使用 Visual SourceSafe（糟糕！）进行源代码控制。

【讨论】：

【解决方案3】：

我一直在寻找一种 SQL Server 源代码控制工具 - 并且遇到了许多可以完成这项工作的高级版本 - 使用 SQL Server Management Studio 作为插件。

LiquiBase 是免费的，但我从来没有完全满足我的需求。

还有另一种免费产品，尽管它与 SSMS 并驾齐驱，并将对象和数据脚本化为平面文件。

然后可以将这些对象注入到一个新的 SQL Server 实例中，然后该实例将重新创建数据库对象。

【讨论】：

【解决方案4】：

也许你要LiquiBase？

【讨论】：