Question

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

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

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

示例：

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

Answer 1

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

db/views/your_stuff.view.sql

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

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启动分支A并添加新列。他们修改SELECT 'x' FROM foos以反映这一变化;他们的迁移只是运行新视图。
开发人员2启动分支B并添加新列。他们修改同一个文件，并像上面一样添加新的迁移。
开发人员2首先完成她的分支并运行迁移。该视图现在看起来像SELECT＆＃39; x＆＃39;，＆＃39; z＆＃39;。
开发人员1现在完成他的分支。但是，要合并到master，他必须解决视图文件中的冲突。一旦他这样做并运行迁移，视图现在包括所有三列。

Answer 2

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

那就是说，我认为架构应该被视为它自己的项目＆＃34;。您提到多个开发人员更改共享VIEW，而不是更改共享dll中常用函数签名的人员。

我的回答是（如果开发还为时已晚）在MySQL用户下连接标准客户端代码，该用户无权更改数据库而不必要;并且有一个＆＃34;迁移＆＃34; application / script /使用用户帐户下的连接运行的任何内容，具有更改表，视图，过程等所需的权限...

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

2 个答案: