sql-server - RedGate SQL 源代码管理适合我吗？

Question

关闭。这个问题是 opinion-based 。目前不接受答案。

---

想要改进这个问题吗？更新问题，以便 editing this post 可以用事实和引文来回答它。 .

已关闭 9 年前。

Improve this question

我刚刚继承了一个 SQL Server 数据库。我需要解决的事情之一是版本控制和自动构建。

有人建议我应该认真考虑推荐 RedGate SQL Compare，但我不得不承认我对此有点不安。

我的预订是...

• 它似乎提倡使用 GUI 工具进行数据库工作？
• 对于实时应用程序，我更喜欢使用更改脚本，这可以避免在每个 scrum 周期结束时创建迁移脚本的最后一刻 panic ，并且这意味着您的更新脚本可以由 CI 进行测试。我不明白 RedGate 工具如何解决这个问题。

我的直觉告诉我要坚持使用经过尝试和测试的 MSBuild 文件和一堆 .SQL 文件的方法。

我很想听听是否有人有使用此工具的经验。

Answer 1

我们使用 Red Gate 生成部署脚本并控制版本控制。

“部署”和“版本控制”对于 SQL 代码来说是不同的问题。

重要注意事项:您的生产数据库是其所有数据的主数据库。因此，将常规副本安排到测试服务器并使用它作为基线。一个NUnit每天晚上用基本数据生成的数据库(看到了，笑了)一般没什么用。如果您有十亿行并且需要针对它测试查询怎么办？

版本控制:您可以使用 Red Gate 工具生成架构作为基线，然后将其与此副本(或您的 QA 或其他内容)进行比较。 Red Gate 工具允许与文件夹进行比较，在我们的例子中该文件夹受 SVN 控制，并且每个版本都会更新。所以我们有每个对象的完整历史记录

部署:我们将开发脚本(也在 SVN 中)应用于干净的“构建”数据库，并与另一个干净的数据库进行比较。这成为我们的部署脚本。

这当然是相当简单的。

专业版提供用于同步和比较的 API，以便您可以根据需要集成到您的工具链中。无需图形用户界面。顺便说一句，我们使用它来提供一些带有客户端代码的特殊用户沙箱的一键同步。

正如 Remus 提到的，它们对于某些操作来说并不是万无一失的。如果您要更改 1.5TB 表上的内容，我会很乐意手工编写我的脚本。另一个令人恼火的地方是，Red Gate 的工具习惯于将 SCHEMABINDING 放在相关 View 或 udf 上，以进行简单的检查约束更改。

我还建议阅读 Martin Fowler 的 "Evolutionary Database Design"寻求一些灵感