数据库结构和源代码控制 - 最佳实践

Question

背景

我在一家公司工作了几年，所有数据库对象都存储在源代码管理中，每个对象一个文件。我们有一份添加新项目时维护的所有对象的列表（以允许我们按顺序运行脚本并处理依赖关系）和一个 VB 脚本，该脚本运行以创建一个针对数据库运行的大脚本。

所有表都是“如果不存在则创建”，所有 SP 等都被删除并重新创建。

到目前为止，我现在工作的地方以数据库为主，并且没有数据库对象的源代码控制，但我们确实使用 redgate 的工具来更新我们的生产数据库（SQL 比较），这非常方便，并且需要很少的工作。

问题

您如何处理数据库对象？我喜欢将它们置于源代码控制之下（并且，当我们使用 GIT 时，我希望能够处理脚本中的合并冲突，而不是数据库中的冲突），但我将被迫过去使用 SQL 来更新数据库比较容易。

我真的不想让我们在 GIT 中更新脚本，然后使用 SQL 比较从我们的 DEV DB 更新生产数据库，因为我宁愿拥有“事实的一个版本”，但我真的不想重新编写一个自定义软件，将所有脚本捆绑在一起。

我认为 Visual Studio 数据库版本可能会做类似的事情，但我不确定我们是否有预算。

我确信这已经被问死了，但我找不到任何似乎完全有我正在寻找的答案的东西。 与此类似，但不完全相同：

代码控制下的数据库脚本的最佳实践是什么

---

开始赏金，因为我有兴趣征求更多意见 - 这里的答案是合理的，但我觉得确实应该有一个更简单的方法。

感谢所有出色的答案 - 都有各自的优点，所以我将投最高票，但为所有的投入欢呼。

Answer 1

看看这个关于数据库版本控制的原理和实践的五部分系列（作者：K. Scott Allen）：

1. 数据库工作的三个规则
2. 基线
3. 更改脚本
4. 视图、存储过程等
5. 分支和合并

这五个部分很重要，但基本上的想法是有一个基线，然后更改脚本（使用版本表）。更新数据库意味着应用当前版本“之上”的更改脚本。而且这个策略对VCS非常友好（没有冲突）。

Answer 2

我们使用 Visual Studio Database Edition (DBPro) 将所有数据库对象置于源代码控制之下。它是一个很棒的工具，可以版本控制我们的模式，进行构建、验证，允许代码分析、模式比较、部署、数据比较、重构等。它从头开始设计为一个数据库管理和版本控制系统。强烈推荐。

这是 DBPro 首席架构师的博客网站：

Answer 3

使用第 3 方 SSMS 插件ApexSQL Source Control，可以自动编写数据库对象脚本并将其推送到远程 Git 存储库，如果您更喜欢使用本地存储库，甚至可以克隆到本地存储库。

ApexSQL 源代码控制支持开箱即用的 Git 源代码控制系统。这意味着您不需要安装任何额外的 Git 客户端。除此之外，分支和合并是集成的，并可通过加载项 UI 进行使用。

Answer 4

假设您使用 .net 框架，请查看 Fluent Migrator 以及 聆听有关该项目的代码播客。
我认为主要目标是轻松地对迁移进行编码，就像使用与数据库无关的方法使用流畅的界面进行正常编码一样。

它构建在 .net 框架之上。并适用于多种数据库格式，包括 SQL Server、SqlLite 和 MySQL。

这种方法的优点是它与代码的其余部分一起存在，因此可以由 SCM

示例进行管理：

   [Migration(1)]   
   public class CreateProjectsTable : Migration   
   {   
       public void Up()   
       {   
          Create.Table("Projects")              
            .WithIdColumn()             
            .WithColumn("Name").AsString().NotNullable()                
            .WithColumn("Position").AsInt32().NotNullable()             
            .WithColumn("Done").AsBoolean().NotNullable();
       }  
       public void Down()  
       {  
           Database.RemoveTable("Projects");  
       }  
   }

Answer 5

如果您已经在使用 Red Gate 工具，则可以考虑使用 SQL 源代码管理，它与 SQL Compare 和 SQL Data Compare 并行工作，以允许源代码管理中存在一种事实版本。目前尚处于早期访问阶段，但大部分功能都可供试用。您可以从 http://www.red-gate.com/Products 下载此文件/SQL_Source_Control/index.htm 。但目前仅支持SVN和TFS。你标准化了 GIT 吗？

David（红门产品经理）

Answer 6

我们有一个系统，其中数据库名义上是我们的源代码控制系统中的主机，我们维护一系列“架构更改”脚本（.sql 文件），每个脚本负责幂等地回滚更改，然后应用它。每个脚本都只是编号，因此我们有 000.sql（用于创建数据库并设置标准对象）、001.sql 等。

在开发过程中，开发人员编写架构更改脚本并针对开发数据库运行它。每个更改都需要在 dba.change_info 表中添加一行，其中包含更改编号和简要说明。为了回滚更改，只需运行它的第一部分即可。对于 SQL Server，回滚部分的幂等性是通过在发出 DROP 命令之前检查 sysobjects 等来处理的 - 类似于“drop ... if contains”结构。如果要更改模型而不是简单地添加模型，则架构更改可能需要进行数据迁移，并且还用于维护参考数据。

在发布过程中，DBA（我们是一家小公司，所以这是由开发人员之一担任的角色）在停止旧版本的应用程序和启动之间将发布的架构更改应用到生产数据库更新的。

这完全是一个手动过程，但满足了诸如将数据从一个模型迁移到另一个模型等要求：例如，将布尔标志扩展为一组选项，或者将多对一关联转换为多对多关联。无论如何，这通常不是可以使用简单的模式比较工具生成的东西。它还允许角色分离 - 尽管实际上我们都可以完全访问生产，但那里有足够的解耦，以便“DBA”可以读取和审查要在生产中应用的 .sql 文件。

至少从理论上讲，只需按照 000.sql 的顺序运行所有模式更改即可构建完整的数据库（仅包含参考数据）。在实践中，我们并不定期这样做，而是将生产数据库复制到开发人员，然后在发布之前运行回归测试之前应用更改脚本。这用于测试更改脚本本身，但仅适用于中等规模的生产数据库。

Answer 7

我对 RedGate 工具包不是很熟悉，但它是否与 dbGhost，必须有一个实用程序允许您将数据库对象编写为每个对象一个文件的脚本。在这种情况下，我建议执行以下操作：

• 添加每日（或构建的一部分）作业，将 DEV 数据库逆向工程到目录结构中，
• 然后将其与存储库中的内容进行比较（通过简单的 diff），基本上构建作业失败并报告diff（如果有）。这将表明DEV数据库的结构已更改并且未反映在源代码管理中，
• 这将指示开发人员将更改添加到源代码管理中（甚至使用报告的.diff文件为此）

如果您有许多 DEV 数据库（每个用户或开发分支一个）并且太麻烦，那么更好的组合可能是在 STAGE（发布前测试）版本上执行此类任务数据库的，此时您可以将 PROD 模式存储在存储库中，并且仅在预发布测试阶段从 STAGE 更新它，在此阶段您将确保您的模式更改也位于存储库中。

这样，开发人员仍然可以按照通常的方式工作：首先更改 DEV 数据库上的架构，希望您能在您想要的灵活性和单一事实之间取得平衡。

在我的团队中，一旦更改 DEV 数据库，我们就会立即对 VCS 进行更改，但我们仍然有这样的任务来比较不同数据库（DEV、STAGE 和 PROD）之间的模式。基本上，我们遵循我曾经在 How 中回答的内容您应该从源代码控制构建数据库吗？。

Answer 8

在工作中，我们大量使用一个强大的工具，它是 ActiveRecord 的一部分（这是 Rails Web 框架附带的默认 ORM，名为 迁移。

基本迁移如下所示：

class AddSystems < ActiveRecord::Migration
  def self.up
    create_table :systems do |t|
      t.string  :name
      t.string  :label
      t.text    :value
      t.string  :type
      t.integer :position, :default => 1
      t.timestamps
    end
  end

  def self.down
    drop_table :systems
  end
end

为每个数据库更改创建一个迁移，并且它们是按顺序创建的您可以运行预定义的方法以正确的顺序运行这些迁移，以便始终可以创建和/或回滚数据库，其中一些功能如下：

rake db:migrate #run all outstanding migrations
rake db:rollback #roll back the last run migration
rake db:seed #fill the database with your seed data

迁移具有用于创建表、删除表、更新的方法。表、添加索引等。全套迁移还会自动添加一个 id 列，并且 t.timestamps 部分自动生成一个“created_at”字段和一个“ update_at”字段。

大多数语言都有诸如此类的 ORM 工具，它们允许数据库以类似代码的状态进行维护，这对于开发人员来说很容易理解，并且对于 DBA 来说也足够简单使用和维护。

Answer 9

我目前在建模工具（DeZine for Databases）中维护数据库设计，并将其存储在源代码控制下。在我的表设计中，我添加了一个包含两行的表，其中包含架构和参考数据的版本号，每次更改/发布数据库时都会更新该表（用户不访问该表）。

参考数据保存在 Excel 电子表格中（也在源代码控制下），该电子表格可以生成 INSERT 语句的 SQL 脚本来填充新数据库。

当需要新版本时，会发送架构脚本、参考数据脚本和安装程序包。安装程序包重命名旧数据库，从脚本创建新数据库并导入新参考数据（也可能已更改）。然后，用户的数据从旧的（重命名的）数据库复制到新数据库。

这样做的优点是，当出现问题时，您可以恢复到原始数据库，因为它尚未被修改。

Answer 10

有一个专门的工具可以解决这个问题。它的名称为 Wizardby：

...数据库持续集成&架构迁移框架

_{（来源：googlecode.com）}