我有三个共享相同数据库的应用程序。所有这三个应用程序都是使用php（Laravel框架）构建的。最初只有一个应用程序，因此我使用Laravel内置的迁移功能（修改/创建/删除表并将这些更改回滚）来管理数据库。这样就可以跟踪我的版本控制中的所有更改。
现在，由于我拥有三个应用程序，我不知道应该在哪里管理数据库。我的真相在哪里？如我所见，我有多种选择：
使用一个应用程序作为“数据库主数据库”。仅此应用程序必须更改数据库的结构。所有其他应用程序只能访问读/写数据。
每个应用程序都会进行自己的更改。这将导致巨大的混乱，因为几乎不可能从零回滚/重建。
使用第三方工具（例如MySQL-Workbench）来编辑我的数据库。在我看来，这是一个有效的选择，因为该工具旨在处理数据库及其结构/数据。但是，是否存在某种版本控制？我可以回滚所做的更改吗？
使用第四个应用程序（在我的示例中为另一个Laravel应用程序）。这个程序只负责数据库。这样就可以跟踪git中的所有更改。
这是我第一次遇到此问题，很高兴收集一些有关最佳做法的信息。
修改 这些应用程序共享相同的表。
答案 0 :(得分：0)
您的问题超出了您所确定的范围。
特别是，问题不仅在于如何在版本控制中跟踪跨应用程序的数据库迁移，还在于跨应用程序的数据库迁移如何影响使用该数据库的其他应用程序。
>例如，假设应用程序A需要更新您适当实现的数据库模式（通过问题中提出的任何方法）。但是应用程序B和C假定该更新之前已存在数据库模式！怎么了？您需要更新应用程序B和C，否则它们会中断。
因此，您的应用程序对数据库的特定版本具有依赖性，就像它们可能对特定版本的第三方库具有依赖性一样。但是，尽管它们可能各自使用特定软件库的不同版本，但它们都必须全部使用相同版本的数据库。
管理此问题需要仔细考虑。大致来说，我建议您将数据库迁移文件放入经过精心包装的“应用程序”中，使用每个应用程序的程序包管理器来跟踪它们对数据库各自版本的依赖性，并确保您的部署脚本验证了产品每个应用程序的版本都与任何新版本兼容（最好是在合适的测试套件通过之后）。
这闻起来有点太脆了。也许您现有的应用程序应该通过专用服务应用程序（例如提供REST或Graphql接口）访问数据库-当该应用程序的API发生更改时，您仍然会遇到版本依赖问题（在Graphql中极为罕见），但管理起来更容易一些（例如，通过在不同位置同时显示多个版本）。