构建和维护一个数据库，然后由许多开发人员进一步深化/开发，这是软件开发中不断发生的事情。我们创建一个构建脚本，并维护随着数据库随时间增长而应用的更新脚本。有许多方法可以解决这个问题，从手动更新到控制台应用程序/构建脚本，可以帮助自动执行这些过程。
是否已将构建/管理这些流程的任何人转移到用于数据库架构管理的源代码管理解决方案？如果是这样，他们找到了什么最好的解决方案？是否有任何应该避免的陷阱？
Red Gate似乎是MSSQL世界中的一个重要参与者，他们的数据库源控件看起来非常有趣： http://www.red-gate.com/products/solutions_for_sql/database_version_control.htm
虽然它看起来不像是取代了（默认）数据*管理流程，但它只替换了我的pov的一半变更管理流程。
（当我谈论数据时，我的意思是查找值和那种事情，默认情况下或在灾难恢复场景中需要部署的数据）
我们在.Net / MSSQL环境中工作，但我确信所有语言的前提都是相同的。
答案 0 :(得分：2)
这些现有问题中的一个或多个可能会有所帮助：
答案 1 :(得分：1)
我负责管理我工作的银行内部开发的数据仓库。这需要不断更新，我们有一个由2-4个开发人员组成的团队。
我们很幸运，因为我们的“产品”只有一个实例，因此我们不必为可能处于不同版本的多个实例进行部署。
我们为数据库中的每个对象（表，视图，索引，存储过程，触发器）保留一个创建脚本文件。
我们尽可能避免使用ALTER TABLE，更喜欢重命名表，创建新表并迁移数据。这意味着我们不必查看ALTER脚本的历史记录 - 我们总是可以通过查看其创建脚本来查看每个表的最新版本。迁移由单独的迁移脚本执行 - 这可以部分自动生成。
每次发布时，我们都会有一个脚本，它以适当的顺序运行创建脚本/迁移脚本。
仅供参考：我们使用Visual SourceSafe（yuck！）进行源代码控制。
答案 2 :(得分：1)
我一直在寻找一个SQL Server源代码控制工具 - 并且使用SQL Server Management Studio作为插件，遇到了许多完成这项工作的高级版本。
LiquiBase是一个免费的，但我从来没有完全满足我的需求。
还有另一个免费产品，虽然它可以从SSMS中运行，并将对象和数据编写到平面文件中。
然后可以将这些对象泵入新的SQL Server实例，然后重新创建数据库对象。
请参阅gitSQL
答案 3 :(得分：0)
也许您要求LiquiBase？