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

Question

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

我们一直在使用数据库迁移库来进行所有模式更改,但是当不同代码分支中的不同开发人员改变同一视图时,它们遇到了问题,但它们的起源点是相同的.

每个开发人员都有自己的数据库副本,但由于视图通常需要在迁移中指定整个定义,这意味着当我们对登台或生产数据库运行迁移时,无论哪个视图迁移最后都会覆盖任何在任何先前的视图迁移中所做的更改.

例:

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 用户下进行连接，而该用户没有必要的权限来更改数据库；并拥有一个“迁移”应用程序/脚本/在用户帐户下通过连接运行的任何内容，并具有更改表、视图、过程等所需的权限...