任何人都使用Red Gate的SQL Source Control

Question

我们一直在研究SQL Source控件的可能解决方案.我刚刚遇到Red Gates SQL Source控件,想知道是否有人实现了它？我将下载试用版并试一试,但只是想看看其他人是否有真正的经验.

一如既往地非常欣赏输入

--S

Answer 1

我已更新下面的原始帖子,以反映最新版本的SQL源代码控制(3.0)和SQL比较(10.1)的更改.

由于这个问题是在一年前提出的,我的回答可能对您没有帮助,但对于目前正在评估SSC的其他人,我认为我会投入两分钱.我们刚刚开始使用SQL源代码控制(SSC),总体而言我到目前为止对此非常满意.它确实有一些怪癖,特别是如果你在共享数据库环境中工作(而不是每个在本地工作的开发人员),特别是在遗留环境中工作,同一数据库中的对象在开发团队之间随意分配.

为了简要概述我们如何在组织中使用该产品,我们正在共享环境中工作,我们都对同一个开发数据库进行了更改,因此我们将共享数据库附加到源控制存储库.每个开发人员都负责通过SQL Server Management Studio(SSMS)对数据库中的对象进行更改,完成后,他们可以将更改提交给源代码管理.当我们准备部署到分段时,构建主机(我)将数据库代码的开发分支合并到主(分段)分支,然后使用数据库的主分支库版本作为源和现场运行SQL Compare将数据库暂存为目标,SQL Compare生成必要的脚本以部署对暂存环境所做的更改.分阶段到生产部署以类似的方式工作.另外需要注意的另一点是,鉴于我们与其他开发团队共享同一个数据库,我们使用SSC的内置功能,允许您按名称,类型等在数据库对象上创建过滤器.我们手动在我们特定团队的对象上设置过滤器,排除所有其他对象,这样我们在部署时不会意外地提交其他开发团队的更改.

所以一般来说它是一个相当简单的设置和使用产品,它非常好用,因为你总是使用SSMS中的活动对象,而不是存储在单独的源存储库中的断开连接的脚本文件,这些文件存在不同步的风险.它也很好,因为SQL Compare会为您生成部署脚本,因此您不必像在自己创建脚本时那样担心引入错误.而且,由于SQL Compare是一个非常成熟和稳定的产品,您可以非常自信它将为您创建适当的脚本.

然而,话虽如此,这里有一些我到目前为止遇到的怪癖:

• 在与数据库服务器通信方面,SSC开箱即用,以便跟踪与源控制存储库不同步的数据库项.它每隔几毫秒轮询一次,如果你添加了多个使用SSC对同一个数据库工作的开发人员,你可以想象我们的dba不是很开心.幸运的是,您可以轻松地将轮询频率降低到更可接受的水平,但代价是牺牲了对象更改时的响应式视觉通知.
• 使用对象过滤功能,您无法通过查看SSMS中的对象轻松判断过滤器中包含哪些对象.因此,您不确定对象是否受源代码控制,这与Visual Studio不同,后者的图标用于指示源控制对象.
• 对象过滤GUI非常笨重.由于我们在遗留数据库环境中工作,目前我们团队拥有的对象与其他团队拥有的对象之间没有明确的分离,因此为了防止我们意外地提交/部署其他团队的更改,我们已经设置了一个过滤方案,以明确包含我们拥有的每个特定对象.你可以想象,这变得相当麻烦,并且由于编辑过滤器的GUI设置为一次输入一个对象,它可能会变得相当痛苦,尤其是第一次尝试设置环境时(我最终编写应用程序来执行此操作).展望未来,我们正在为我们的应用程序创建一个新的模式,以便更好地促进对象过滤(无论如何还是一个更好的实践).
• 使用共享数据库模型,允许开发人员将任何挂起的更改提交到源控制的数据库,即使更改不是他们的.如果您尝试检查这些更改可能不属于您的更改,SSC会给您一个警告,但除此之外您自己就是这样.我实际上发现这是SSC最危险的"怪癖"之一.
• SQL Compare目前无法共享SSC创建的对象过滤器,因此您必须在SQL Compare中手动创建匹配过滤器,因此存在这些过滤器可能不同步的危险.我刚刚将过滤器从底层SSC过滤器文件中剪切并粘贴到SQL Compare项目过滤器中,以避免处理笨重的对象过滤GUI.我相信下一版本的SQL Compare将允许它与SSC共享过滤器,所以至少这个问题只是一个短期问题.(注意:此问题已在最新版本的SQL Compare中得到解决.SQL Compare现在可以使用SSC创建的对象过滤器.)
• 直接启动时,SQL Compare也无法与SSC数据库存储库进行比较.它必须从SSMS内部启动.我相信下一版本的SQL Compare将提供此功能,因此这又是另一个短期问题.(注意:此问题已在最新版本的SQL Compare中得到解决.)
• 有时,SQL Compare无法创建正确的脚本来将目标数据库从一种状态转换到另一种状态,通常是在您更新非空的现有表的模式的情况下,因此您当前必须编写手动脚本并自己管理流程.幸运的是,这将通过下一版SSC中的"迁移脚本"来解决,从查看产品的早期发布版本来看,这个新功能的实现似乎经过了深思熟虑和设计.(注意:迁移脚本功能已正式发布.但是,它目前不支持分支.如果要使用迁移脚本,则需要对原始开发代码分支运行sql compare ...您签入的那个你的更改...这是非常笨重的,并迫使我以一种不太理想的方式修改我的构建过程,以解决这个限制.希望这将在未来的版本中得到解决.)

总的来说,我对产品和Redgate对用户反馈的响应以及产品的使用方向非常满意.该产品非常易于使用且设计精良,我觉得在下一个或两个版本中,该产品可能会给我们提供最多(如果不是全部)所需的产品.

Answer 2

我从开发 - >测试 - >生产时使用SQL Compare生成脚本,这节省了大量的时间.

但是对于源代码控制,我们使用SVN和ScriptDB(http://scriptdb.codeplex.com/).我主要使用SQL脚本的源代码控制来跟踪更改.我认为很少(如果有的话)回滚数据库的版本,因为在进行结构更改时数据可能已经改变.

这适用于我们当前的一些项目(最大的是200个表和2000个sprocs).这样做的主要原因是成本,因为并非所有团队成员都必须购买SQL Compare(我避免在商业项目中添加依赖项,除非确实需要).