我一直在尝试使用Liquibase或DBDeploy。我更倾向于Liquibase，因为它的非SQL接口（I.E.我只能使用JSON或Yaml更改集）。但是，我对这两个软件都存在问题。
includeAll一个文件夹，其中包含里面有小变更集的小文件。嗯，这个问题是如此微不足道，我觉得这个问题很愚蠢，但就在这里。请考虑以下情况：
这不会发生在任何人身上吗？如果是这样，那么在PHP领域解决它的方法是什么？
感谢。
答案 0 :(得分：2)
（我只知道liquibase - 所以我的答案只适用于liquibase）
正如includeAll doc所述，文件将按字母顺序运行。所以我希望你的编号应该足以使文件的顺序正确。
但是，您必须在您和Bob之间同步这些数字，以找出首先要运行的数字。
我们不使用includeAll。我们手动将文件包含在主更新日志中。因此，无论谁想要更改数据库，都必须将其包含在主更改日志中。如果有两个更改，最后一个开发人员必须确保在主更改日志中的正确位置包含/合并他的更改。
已编辑 - 解释我们使用的包含机制
在开发中，我们只是忽略整个数据库，让liquibase在我们改变任何东西时（从我们的开发数据库）创建数据库。 我们总是将changeset文件签入我们的代码库。因此，我们跟踪在开发中完成的所有内容，因为我们可以检出变更集的每个版本，并让liquibase使用它创建数据库。
只有在我们正在进行的版本（或sprint）的开发完成时。然后我们真的让变更集运行，让他们改变生产数据库。
然后一次又一次地重复这个循环。
这样，只使用liquibase跟踪最终的数据库更改，而不是在开发过程中可能发生的所有尝试。
在开发过程中，您可能会多次更改表格，因为您尝试了不同的东西。您添加一列，然后意识到整个事情将无法工作，因此您再次删除该列并添加另一列。为什么要在databasechangelog中进行所有这些更改？然后它会填满不必要的东西 - 就像你害怕的那样。
希望这可以解决问题。但最终你可能会有一个完全不同的开发方法。因此，您可以根据需要随意使用liquibase。
没有理由在开发期间用databasechangelog表填充所有想法。只有当我们完成开发并发布版本
时答案 1 :(得分：2)
我使用了几个不同的迁移框架--Liquibase，Rails和来自C＃世界的名为Tarantino的东西。每个都使用类似的策略，其中更改记录在单独的文件中。每个人都在一个小团队（＆lt; = 5开发人员）。
Rails是关于如何命名文件的最教条的，并且是由于分支而导致冲突最多的地方。大多数冲突都是基于名称的，而不是数据库中的逻辑冲突。
在使用Liquibase的项目中，我们使用了master / include模式，开发人员在分支上完成了他们的工作。因为文件名有3位数序列号加上简短描述（即009-add-customer0index.xml），所以我们没有名称冲突。我们主要是通过彼此交谈来避免数据库级冲突 - 每日站立等等。
我们使用Tarantino有类似的经历，尽管它只使用一个充满文件的目录进行迁移。与Liquibase一样，我们采用了一种保持秩序的命名约定。即使两个变更集具有相同的数字，它们也会有不同的名称，而99.9％的时间，这两个变更集的顺序并不相互依赖。
对于一个数据点，使用Tarantino的项目平稳了大约400个变更集。