RedGate SQL源代码管理是否适合我？

Question

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

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

我的预订是..。

• 它似乎在推广使用gui工具进行数据库工作？
• 对于实时应用程序，我更喜欢使用变更脚本，这避免了在每个scrum循环结束时创建迁移脚本的最后一分钟恐慌，这意味着您的更新脚本可以通过CI进行测试。我看不出RedGate工具是如何解决这个问题的。

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

我很想知道是否有人有使用这个工具的经验。

Answer 1

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

“部署”和“版本控制”是SQL代码的单独问题。

需要注意的是:您的生产数据库是掌握所有数据的主数据库。因此，将定期副本安排到测试服务器，并将其用作基线。每天晚上由NUnit生成的带有基本数据的数据库(见过，笑过)通常都是无用的。如果您有10亿行，并且需要测试对它的查询，该怎么办？

版本控制:您可以使用Red工具作为基线生成模式，然后将其与此副本(或QA或其他任何内容)进行比较。release工具允许与文件夹进行比较，在我们的示例中，该文件夹在SVN控制下，并且在每个版本中都会被更新。所以我们有每个物体的完整历史

部署:我们将我们的开发脚本(也是在SVN中)应用于一个干净的"build“DB，并与另一个干净的DB进行比较。这将成为我们的部署脚本。

当然，这是相当简单的。

pro版本提供了一个API来同步和比较，这样您就可以在需要时集成到您的工具链中。不需要GUI。顺便说一句，我们使用它提供了一些特殊用户沙箱的一键同步，并附带了客户端代码。

正如Remus提到的，对于某些操作来说，它们并不是万无一失的。如果您要更改1.5TB表上的内容，我会非常喜欢地手工编写我的脚本。另一个恼人之处是related的工具习惯于将SCHEMABINDING放在相关的视图或udf上，以进行简单的检查约束更改。

我还建议阅读马丁·福勒的““进化数据库设计””，以获得一些启示。

Answer 2

我也更喜欢脚本--易于存储在源代码管理(CVS、Git等)中，这样您就可以通过不同的方式查看更改的时间。

Answer 3

我不相信基于diff的部署工具。这包括vsdbcmd .schema文件，因为它们也是基于差异的。上一次我尝试使用diff工具，它很高兴地提供了通过复制/删除/重命名来更改1.5TB表.

我的方法是始终使用升级脚本，将部署的模式从v. N移到v. N+1。这样我就能准确地知道升级是如何完成的，如果一个操作是不可能的(它需要一个持续2周的数据拷贝操作)。然后，我知道我不能这样做，我计划了我的代码更改，以便相应地发布v.Next。