数据库源代码控制对比架构更改脚本

题

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

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

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

虽然它看起来并没有取代（默认）数据*管理流程，所以它只取代了我的观点的一半变更管理流程。

（当我谈论数据时，我指的是查找值之类的东西，需要默认部署或在灾难恢复场景中部署的数据）

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

解决方案

这些现有问题中的一个或多个可能有用：

其他提示

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

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

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

我们避免使用 ALTER TABLE 只要有可能，最好重命名表、创建新表并迁移数据。这意味着我们不必回顾历史 ALTER 脚本 - 我们始终可以通过查看每个表的创建脚本来查看其最新版本。迁移由单独的迁移脚本执行 - 这可以部分自动生成。

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

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

我一直在寻找一个SQL Server源控制工具 - 并遇到了很多完成作业的高级版本 - 使用SQL Server Management Studio作为插件。

Liquibase是一个免费的，但我从未如此以满足我的需求。

在那里有另一个免费的产品，虽然从SSMS和脚本出来对象和数据到平面文件。

然后可以将这些对象泵入新的SQL Server实例，然后将重新创建数据库对象。

可能是你要求 liquibase ？

许可以下： CC-BY-SA 和归因