在多开发人员环境中处理数据库视图的迁移

Question

对于如何在多开发人员/多分支 (VCS) 环境中成功处理数据库视图的迁移，是否有任何既定做法？

我们一直在为所有架构更改使用数据库迁移库，但是当不同代码分支中的不同开发人员更改相同视图但他们的起点相同时遇到了问题。

每个开发人员都有自己的数据库副本，但由于视图通常需要在迁移中指定整个定义，这意味着当我们针对暂存数据库或生产数据库运行迁移时，无论运行哪个视图迁移last 覆盖在任何以前的视图迁移中所做的任何更改。

示例：

1. 当前视图如下：SELECT 'x'。
2. 开发人员 1 启动分支 A 并添加一个新列。他们的“向上”迁移看起来像：SELECT 'x', 'y'。
3. 开发人员 2 启动分支 B 并添加一个新列。他们的“向上”迁移看起来像：SELECT 'x', 'z'。
4. 开发人员 2 首先完成她的分支并运行迁移。视图现在看起来像 SELECT 'x', 'z'。
5. 开发人员 1 现在完成他的分支并运行迁移。视图现在看起来像 SELECT 'x', 'y' 并且开发人员 2 的更改已丢失。

Answer 1

对于可以随时重新定义的视图或任何数据库对象（例如函数），我发现的最佳实践是将函数的当前定义存储在其自己的文件中，例如db/views/your_stuff.view.sql；然后，每当开发人员想要更改该视图时，他们都会更改该文件，然后添加一个样板迁移，它只是从最新版本重新定义视图（我不知道您是否在 Rails 中，但这里的想法应该很清楚）：

class UpdateYourStuffView < ActiveRecord::Migration
  def up
    execute File.read("#{Rails.root}/db/views/your_stuff.view.sql")
  end

  def down
    # You could expand this to actually track older versions, 
    # but that's generally not worth it.
    raise ActiveRecord::IrreversibleMigration
  end
end

请注意，实际的视图文件应如下所示：

CREATE OR REPLACE VIEW your_stuff AS (SELECT 'x' FROM foos);

这解决了你的问题，因为现在的工作流程是：

1. 当前视图如下：SELECT 'x' FROM foos。
2. 开发人员 1 启动分支 A 并添加一个新列。他们修改db/views/your_stuff.view.sql 以反映这一变化；他们的迁移只是运行新视图。
3. 开发人员 2 启动分支 B 并添加一个新列。他们修改了同一个文件，并添加了一个新的迁移，就像上面一样。
4. 开发人员 2 首先完成她的分支并运行迁移。视图现在看起来像 SELECT 'x', 'z'。
5. 开发人员 1 现在完成了他的分支。但是，要合并到 master，他必须解决视图文件中的冲突。完成并运行迁移后，视图现在包含所有三列。

Answer 2

如果他们在不同的代码分支中工作，他们应该使用不同的数据库；当分支合并时，应该解决差异。

也就是说，我认为架构应该被视为它自己的“项目”。您提到了多个开发人员更改共享 VIEW，而更改的意义不亚于某人更改共享 dll 中常用函数的签名。

我的回答是（如果开发还不算太晚的话）在一个 MySQL 用户下连接标准客户端代码，该用户没有必要的更改数据库的权限；并拥有一个“迁移”应用程序/脚本/任何在用户帐户下通过连接运行的程序，该用户帐户具有更改表、视图、过程等所需的权限...