RedGate SQL源代码管理适合我吗? [英] Is RedGate SQL Source Control for me?

问题描述

我刚刚继承了一个SQL Server数据库.我需要弄清的一件事是版本控制和自动构建.

I've just inherited an SQL Server database. One of the things I will need to sort out is versioning and automated builds.

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

It has been suggested that I should think seriously about recommending RedGate SQL Compare, but I have to admit I am a little uneasy about it.

我的预订是...

• 它似乎促进了gui工具在数据库工作中的使用?
• 对于实时应用程序，我更喜欢使用更改脚本，这样可以避免在每个Scrum周期结束时最后一刻都无法创建迁移脚本，这意味着CI可以测试您的更新脚本.我看不到RedGate工具如何解决这个问题.

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

My gut instinct tells me to stick with the tried and tested approach of an MSBuild file and a stack of .SQL files.

如果有人有使用此工具的经验，我将很感兴趣.

I would be interested to hear if anyone has any experience on using this tool.

推荐答案

我们使用Red Gate生成用于部署和控制版本控制的脚本.

We use Red Gate to generate scripts for deployment and to control versioning.

部署"和版本控制"是SQL代码的独立问题.

"Deployment" and "versioning" are separate issues for SQL code.

重要说明:您的生产数据库是所有数据的主数据库.因此，将常规副本安排到测试服务器，并以此作为基准.通常，由NUnit每晚生成的具有基本数据(看得出来，笑了起来)的数据库是无用的.如果您有十亿行并且需要针对它测试查询怎么办?

Important to note: your production database is master with all it's data. So arrange of regular copies to a test server and use this as a baseline. A database generated by NUnit every night with basic data (seen it, had a laugh) is generally useless. What if you have a billion rows and need to test a query against it?

版本控制:您可以使用Red Gate工具生成一个模式作为基线，然后将其与此副本(或您的质量检查或任何其他内容)进行比较. Red Gate工具允许与文件夹进行比较，在我们的案例中，该文件夹在SVN的控制下，并且在每个版本中都会更新.因此，我们对每个对象都有完整的历史记录

Versioning: You can use the Red Gate tools to generate a schema as a baseline and then compare this to this copy (or your QA or whatever). The Red Gate tools allows comparison to a folder, which is under SVN control in our case and is updated every release. So we have full history of every object

部署:我们将开发脚本(同样在SVN中)应用于干净的"build"数据库，并与另一个干净的DB进行比较.这将成为我们的部署脚本.

Deployment: we apply our development scripts (also in SVN) against a clean "build" DB and compare to another clean DB. This becomes our deployment script.

这当然很简化.

专业版提供了一个用于同步和比较的API，因此您可以根据需要集成到您的工具链中.无需GUI.顺便说一句，我们使用它来提供一些带有客户端代码的特殊用户沙盒的一键式同步.

The pro version offers an API to synch and compare so you can integrate into your tool chain if needed. No GUI needed. Incidently, we use this to provide a one click synch of some special user sandboxes complete with client code.

正如雷木思(Remus)所提到的，对于某些操作，它们并非万无一失.如果您要在1.5TB的表上进行更改，我将手工编写脚本.另一个烦人的事情是，Red Gate的工具有一种习惯，就是将SCHEMABINDING放在相关视图或udf上，以进行简单的检查约束更改.

As Remus mentioned, they aren't foolproof for some operations. If you are changing stuff on 1.5TB tables, I'd lovingly handcode my script. Another irritation is that Red gate's tool has a habit of dropping SCHEMABINDING on a related view or udf for a simply check constraint change.

我还建议您阅读Martin Fowler的进化数据库设计" 以获得一些启发

I also recommend reading Martin Fowler's "Evolutionary Database Design" for some inspiration

这篇关于RedGate SQL源代码管理适合我吗?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！