我们一直在研究SQL源控制的可能解决方案。我刚刚遇到了红门SQL源控制,想知道是否有人实施了它?我要下载审判并试用它,但只想看看其他人是否有真实的经验。

一如既往地感谢输入

-s

有帮助吗?

解决方案

从dev-> test->生产中,我使用SQL比较来生成脚本,并节省了很多时间。

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

这对于我们当前的一些项目(最大的是200张表和2000个Sprocs)都可以正常工作。这样做的主要原因是成本,因为并非所有团队成员都必须购买SQL比较(除非真正需要,否则我避免增加对商业项目的依赖性)。

其他提示

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

由于这个问题是一年前问的,所以我的回答可能对您没有帮助,但是对于目前可能正在评估SSC的其他人,我认为我会付出两分钱。我们刚刚开始使用SQL源控制(SSC),总的来说,到目前为止,我对此感到非常满意。不过,它确实有一些怪癖,尤其是如果您在共享数据库环境中工作(与本地工作的每个开发人员相反),尤其是在旧版环境中工作的情况下,在同一数据库中的对象在开发团队之间随意分配。

为了简要概述我们如何在组织中使用该产品,我们正在共享环境中工作,在该环境中我们都对同一开发数据库进行更改,因此我们将共享数据库附加到源控制存储库。每个开发人员都负责通过SQL Server Management Studio(SSMS)对数据库中的对象进行更改,并且完成后,他们可以将其更改用于源控制。当我们准备部署到分期时,构建主(ME)将数据库代码的开发分支合并为主(登台)分支,然后使用数据库的主分支存储库版本作为源和live运行SQL进行比较分期数据库作为目标,而SQL比较生成必要的脚本来部署对登台环境的更改。生产部署的分阶段以类似的方式工作。要注意的另一个要点是,鉴于我们正在与其他开发团队共享相同的数据库,我们使用SSC内置功能,使您可以按名称,类型等在数据库对象上创建过滤器。在我们特定团队的对象上设置过滤器,不包括所有其他对象,以免我们在部署时不小心进行其他开发团队的更改。

因此,通常这是一个相当简单的产品,可以设置和使用,这真的很不错,因为您一直在使用SSM中的实时对象,而不是存储在单独的源存储库中的断开连接的脚本文件,该文件有可能会出现离开同步的风险。这也很好,因为SQL比较为您生成部署脚本,因此您不必担心如果您自己创建脚本,则不必像引入错误一样。而且由于SQL比较是一种非常成熟且稳定的产品,因此您会非常有信心为您创建适当的脚本。

话虽这么说,但这里有一些我到目前为止遇到的怪癖:

  • 就与DB服务器通信以跟踪与源控制存储库不同步的数据库项目,SSC是开箱即用的。它每隔几毫秒就进行了一次调查,如果您使用SSC添加了与同一数据库一起工作的多个开发人员,您可以想象我们的DBA并不很高兴。幸运的是,您可以轻松地将轮询频率降低到更容易接受的东西,尽管以牺牲对象何时更改的响应式视觉通知为代价。
  • 使用对象过滤功能,您无法轻松地从SSM中查看哪些对象中包含哪些对象。因此,与Visual Studio不同,您不确定一个对象是否处于源控制状态,该对象使用图标指示源控制对象。
  • 对象过滤GUI非常笨拙。由于我们正在旧数据库环境中工作,目前我们的团队拥有的对象与其他团队拥有的对象之间没有明确的分离,因此为了防止我们意外地进行/部署其他团队的更改,我们设置了一个过滤方案,以明确包含我们拥有的每个特定对象。您可以想象,这变得非常笨拙,并且由于设置过滤器的GUI一次进入一个对象,它可能会变得非常痛苦,尤其是试图首次设置您的环境(我最终结束了编写一个应用程序来执行此操作)。展望未来,我们正在为应用程序创建一个新的架构,以更好地促进对象过滤(无论如何还是更好的练习)。
  • 使用共享数据库模型,即使更改不是他们的,开发人员也可以对源控制数据库进行任何待处理更改。如果您试图检查一系列更改可能不是您的更改,但除了您独自一人之外,SSC确实会给您警告。我实际上发现这是SSC最危险的“怪癖”之一。
  • SQL比较当前无法共享由SSC创建的对象过滤器,因此您必须在SQL比较中手动创建匹配过滤器,因此存在危险,可以使这些过滤器摆脱同步。我刚刚最终将过滤器从基础SSC过滤器文件剪切到SQL比较项目过滤器中,以避免处理笨拙的对象过滤GUI。我相信下一个SQL比较将允许其与SSC共享过滤器,因此至少这个问题只是一个短期。 (注意:此问题已在最新版本的SQL比较中解决。SQL比较现在可以使用SSC创建的对象过滤器。)
  • 当直接启动时,SQL比较也无法与SSC数据库存储库进行比较。它必须从SSM中启动。我相信下一个SQL比较将提供此功能,因此再次是另一个短期问题。 (注意:此问题已在最新版本的SQL比较中解决。)
  • 有时SQL比较无法创建适当的脚本来将目标数据库从一个状态转到另一个状态,通常在您更新未空的现有表格的模式的情况下,因此您当前必须编写手动脚本并自己管理过程。幸运的是,这将在SSC的下一个版本中通过“迁移脚本”来解决,并且通过查看产品的早期版本,看来此新功能的实现经过深思熟虑和设计。 (注意:迁移脚本功能已正式发布。但是,它当前不支持分支。如果要使用迁移脚本,则需要运行SQL与原始开发代码分支进行比较...您的更改...这很笨拙,并迫使我以不理想的方式修改我的构建过程以解决此限制。希望这将在以后的版本中解决。)

总体而言,我对产品以及Redgate对用户反馈的响应和产品的响应能力感到非常满意。该产品非常易于使用且设计良好,我觉得在下一两个版本中,该产品可能会给我们最多(如果不是全部)我们所需的产品。

我们对Red Gate的产品进行了广泛的评估,并发现了一些主要缺陷。如果您想看看谁更改了一个对象,那就做不到 没有 Sysadmin特权。产品需要查看服务器上的跟踪,这需要这些权利。我是一个5个以上的人团队,不知道谁进行了待处理的变化,这将阻止我们使用该产品。

我刚刚开始为一家新公司工作,他们为其所有项目使用Redgate SQL源控制,并将其添加到一个大型而复杂的项目中。它与TFS同时完成了工作。从我的角度来看,唯一的缺点是SQL Server Management Studio集成非常不稳定。安装工具时,经常发生SQL Server Management Studio的崩溃。

许可以下: CC-BY-SA归因
不隶属于 StackOverflow
scroll top