sql-server - SQL Server 源代码控制

Question

关闭。这个问题是 opinion-based 。目前不接受答案。

---

想要改进这个问题吗？更新问题，以便 editing this post 可以用事实和引文来回答它。 .

已关闭 8 年前。

Improve this question

当我们第一次开始源代码控制时，开发人员只需编辑数据库中的脚本，然后在发布之前，将进行所有更改的一个大脚本。这种方法非常有效，直到一位开发人员意外删除了一个存储过程，所有工作都丢失了。

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

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

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

Answer 1

我们一直在使用Visual Studio Team System Database Edition最近，我不得不说效果非常好。所有存储过程都存储为文件，并 checkin 和 checkout 源代码管理，并且它具有生成脚本等工具。

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

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

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

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

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

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