SQL Server源代码管理

zac*_*ary 22 sql-server version-control

当我们第一次启动源代码控制时,开发人员只需编辑数据库中的脚本,就在发布之前,将会发布所有更改的大脚本.这很有效,直到其中一个开发人员意外删除了存储过程并且所有工作都丢失了.

之后,我们将所有脚本放在文本文件中创建存储过程并将它们存储在源代码管理中.这里的问题是开发人员有时会更新源代码管理或数据库中的存储过程而忘记更新另一个.

我的梦想是建立一个dev进入系统并检查存储过程的系统.然后,在进行更改后,数据库将自动更新.

这只是一个梦吗?源代码控制SQL Server的最佳方法是什么?

Sco*_*ock 11

我们最近一直在使用Visual Studio Team System Database Edition,我不得不说它运行得很好.所有存储过程都存储为文件,并检入和检出源控件,并且它具有生成脚本等的工具.

此外,在过去,我们使用存储为文本文件的脚本,这些脚本在源代码管理中签入和签出.规则是您必须检出文件,然后在例如Management Studio中对其进行编辑,并将其保存并重新检入.在每个存储过程脚本文件的顶部,它将删除现有的存储过程,然后使用CREATE语句创建一个新的(解决CREATE/ALTER问题).然后我们有一个工具可以按正确的顺序运行所有脚本,从头开始构建一个空白数据库,然后我们使用RedGate的SQL Compare产品生成一个脚本,使我们现有的数据库保持最新.我承认这很乏味.

大约在同一时间,我与大约10个其他开发人员一起工作,他们实施了严格的数据库变更管理程序.有许多应用程序都依赖于一组2或3个数据库.每当数据库模式必须改变时(我们只是在这里讨论表,列和视图),然后创建一个文档来解释更改,然后有一个矩阵列出了更改与我们认为会影响的应用程序.然后该文件被传播,并且必须由负责每个应用程序的人员进行审查,并且他们必须在他们的应用程序中搜索它可能受到影响的任何地方等.这是一个漫长的艰巨程序,但它起作用.但是,存储过程只是作为文本文件存储在源代码管理中.

在更遥远的过去,较小的项目更像是桌面应用程序,数据库作为数据存储区,每次应用程序启动时,我会:

  • 检查数据库是否存在,如果不存在,则创建它
  • 检查是否存在所有表,如果不存在,则创建它们
  • 检查是否存在所有列,如果不存在,请添加它们

每当我需要更改架构时,我只需在启动代码的末尾添加更多代码,以根据需要修改架构,注意迁移任何现有数据.这样做的好处是您可以卸载并重新安装新版本的软件,它会自动将现有数据库升级到最新版本.安装,升级和维护是一个梦想.但这不适用于更多"企业"系统.

您可以通过采用ADO.Net实体或其他类似的实体框架(如实体空间)来减少其中一些问题.这些是对象关系映射层.它们为数据库中的每个实体(表)自动生成类,包括每列的属性等.然后,它们允许您使用自定义逻辑扩展这些类.如果您可以远离在存储过程中使用业务逻辑,并将它们放在实体类中,那么好处是它们是强类型的.因此,如果更改列的名称或删除列并重新生成实体类,则IDE或编译器将自动标记代码被破坏的所有位置.显然,所有实体代码自然也在源代码控制中,其余的源代码也是如此.

  • Database Edition,特别是最近推出的新版本,不仅是一个很好的工具,不仅可以用于版本控制,还可以标记不良做法,帮助进行架构更改和重构,尤其是帮助最终用户站点上的部署过程. (2认同)

Dav*_*son 8

Red Gate SQL Source Control将源代码控制完全集成到SQL Server Management Studio.这有效地将您的开发数据库链接到您现有的源代码控制系统(TFS和SVN),允许通过单击按钮提交更改并检索其他开发人员的更改.

http://www.red-gate.com/products/SQL_Source_Control/

我们现在已经为EA版本添加了VSS和SourceGear Vault支持.更多细节:http://www.red-gate.com/MessageBoard/viewtopic.php?t = 12265