您如何管理用于 Visual Studio 项目的 sql server 数据库构建/部署/迁移？
我们的产品包含一个合理的数据库部分（约 100 个表，约 500 个过程/函数/视图），因此我们需要能够部署当前版本的新数据库以及将旧数据库升级到当前版本。目前，我们为创建新数据库和版本之间的迁移维护单独的脚本。显然不理想，但其他人如何处理这个问题？
这对我们来说很复杂，因为有很多客户都有自己的数据库实例，而不是说在我们自己的 Web 服务器上只有 dev/test/live 实例，但是为其他人管理 dev/test/live 的流程必须相似。
更新：我不希望使用任何专有产品，例如 RedGate 的（尽管我一直听说它们非常好，并且会考虑将其作为解决方案）。
【问题讨论】：
标签： sql-server sql-server-2005 deployment database-deployment
我们使用Red-Gate SQLCompare 和 SQLDataCompare 来处理这个问题。这个想法很简单。这两种比较产品都可以让您将选定表（例如配置表）中的模式或数据的完整图像作为脚本维护。然后，您可以将任何数据库与脚本进行比较并获取更改脚本。我们将脚本保存在 Mercurial 源代码控制中，并在每个版本中添加标签（标签）。然后，支持人员可以获取任何版本的脚本，并使用 Redgate 工具从头开始创建或升级。
Redgate 还有一个 API 产品，可让您从代码中执行比较功能。例如，这将允许您在安装程序或产品本身中具有自动升级功能。我们经常将它用于我们托管的 Web 应用程序，因为它使我们能够更全面地自动化推出过程。在我们的例子中，我们有一个 MSBuild 任务，支持人员可以执行该任务来自动推出和升级。如果您分发给第三方，您必须为每个包含 API 的分发支付少量的额外许可费用。
Redgate 还有一个工具可以自动打包数据库安装或升级。我们不使用那个，因为我们发现与一个版本的脚本进行比较为我们提供了更大的灵活性。
Redgate 工具还可以帮助我们进行开发，因为它们使以非常精细的方式对架构和配置数据进行源代码控制变得微不足道（每个数据库对象都可以放在自己的文件中）
【讨论】：
这个问题是在 SSDT 项目出现之前提出的，但这绝对是我现在要采用的方式，以及用于结构数据库更改的手工迁移脚本，其中有数据会受到影响。
【讨论】：
还有 MS VSTS 方法（2008 年描述 here），有人有一篇关于 2010 年的好文章以及使用这些工具的优缺点吗？
【讨论】：