SQL Server源代码管理

Question

当我们第一次开始源代码控制时，开发人员只需要编辑数据库中的脚本，在发布之前，所有更改的一个大脚本就会被制作出来。这很有效，直到一个开发人员意外删除了一个存储过程，所有的工作都丢失了。

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

我的梦想是有一个系统，在这个系统中，开发人员可以进入并签出存储过程。然后，在进行更改后，数据库会自动更新。

这只是一个梦吗？对SQL Server进行源代码管理的最佳方法是什么？

Answer 1

我们最近一直在使用Visual Studio Team System Database Edition，我不得不说它工作得很好。所有存储过程都存储为文件，并签入和签出源代码控制，并且它有生成脚本的工具，等等。

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

大约在同一时间，我与其他大约10名开发人员一起开发了一个系统，他们实现了严格的数据库变更管理程序。有很多很多应用程序都依赖于一组2或3个数据库。每当数据库模式必须更改时(我们这里只讨论表、列和视图)，就会创建一个文档来解释更改，然后会有一个矩阵列出更改与我们认为它将影响的应用程序。然后文件被传阅，必须由负责每个申请的人审查，他们必须在申请中搜索可能受到影响的地方，等等。这是一个漫长而艰巨的程序，但它奏效了。然而，存储的过程只是在源代码控制中存储为文本文件。

在更久远的过去，对于更像桌面应用程序的较小项目，数据库作为数据存储，每次应用程序启动时，我都会：

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

每当我需要更改模式时，我只会在启动代码的末尾添加更多代码，以便根据需要修改模式，同时注意迁移任何现有数据。这样做的好处是，您只需卸载并重新安装新版本的软件，它就会自动将现有数据库升级到最新版本。安装、升级和维护是一个梦想。不过，这对于更多的“企业级”系统是行不通的。

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

Answer 2

Red Gate SQL源代码管理将源代码管理完全集成到SQL Server Management Studio中。这有效地将您的开发数据库链接到现有的源代码控制系统(TFS和SVN)，允许提交更改并只需单击一个按钮即可检索其他开发人员的更改。

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

我们现在已经向EA版本添加了对VSS和SourceGear存储库的支持。更多详细信息请访问：http://www.red-gate.com/MessageBoard/viewtopic.php?t=12265

Answer 3

在我看来，在团队环境中，源代码管理最适合SQL Server的方式是DBA使用签入代码定期构建数据库。通常只有一个实例丢失了一些东西，因为它没有签入，开发人员才明白签入他们的代码是有意义的。

希望这能帮上忙

帐单