在.NET中处理数据库更改/脚本？

我最近开始了一项新工作，他们通过存储过程完成大部分工作。目前，我们有一个源代码管理下的“部署”文件夹，其中包含带有数据库更改脚本的时间戳文件夹（我们实际上有3个文件夹，一个用于表修改脚本，一个用于视图和函数，一个用于存储过程），还有一个“下一个”文件夹，其中包含我们当前正在处理的新更改（当我们进行部署时，它会被重命名）。我们设置了三个数据库：工作站上的本地副本（只有单个开发人员可以访问）、开发数据库和生产中的实时数据库

这意味着我们创建并提交.SQL文件，然后几乎每天都要手动运行它们（因为新的文件被添加到源代码管理中，所以几乎每次进行更新时，我们都需要检查这些文件夹中的更改，并根据数据库的本地副本运行它们），更不用说在部署时必须在dev和prod服务器上执行相同的操作；此外，我们在每台服务器上都有不同的数据库命名，以避免在错误的环境中意外运行更改脚本（这让我感到奇怪，因为通常DB实例的名称不同，但实际数据库的名称在所有服务器上都相同），因此我们不能在脚本中包含

USE

语句。这个过程似乎效率很低

有没有一种处理这类事情的推荐最佳实践方法，我可以建议我们开始使用吗？

请查看

---

您可以使用此工具来比较数据库并为差异创建脚本，或者立即同步数据库

我已经使用Visual Studio数据库项目来处理此问题大约一年了。它有一点学习曲线，并不是完全没有问题，但肯定比尝试管理好手动处理

---

正如其他人所指出的，你应该计划将相当大剂量的“它能处理我们的情况吗？”还有一般的最佳实践。在我的例子中，我有多个开发分支，它们与一些限制性很强的DBA类型的人员一起进入集成环境。这两个分支在过程中都造成了一些复杂问题，我希望您也会遇到类似的情况。

是我们在Red Gate为您推荐的工具o在开发人员之间共享更改。这将集成到SSMS中，并与您现有的源代码管理系统配合使用。SQL Compare最适合用于部署，而不是在开发环境中共享更改等常见用例。如果SQL源代码管理因任何原因无法为您工作，我们希望收到您的来信。

stion：听起来不是陈词滥调，但在这类场景中的最佳实践是非常特定于环境的，并且可能非常固执己见。找出低效点，反复改进流程。不要尝试提供空中楼阁的方法，因为它很可能会被封存。@Aaron:没错，我花了3年时间才从一个巨大的错误中恢复过来一个手动过程与上面的过程非常相似，它是一个光滑的、全自动的“SQL Diff”任务，作为我们持续集成的一部分运行。这是3年来不断进行的小流程更改和改进，一个接一个地构建支持工具。是的，我同时也完成了其他可计费的工作：）