我们正在研究Joomla3.9项目，具有不同的环境，并且正在使用git作为vcs。因此，每个开发人员都在自己的分支机构工作。拥有像TYPO3或Contao这样的数据库比较功能会很好（在更新项目后只需单击一下即可查看数据库差异，并应用数据库更改）。或像laravel迁移系统一样。
在通过后端或其他开发人员进行扩展更新而对数据库进行更改后，任何开发人员都应轻松更新自己的lokal数据库。当然，暂存或实时系统也必须易于更新。我们不想使用phpMyAdmin中的更改来执行sql脚本。 我们已经尝试过https://dbv.vizuina.com/。这不是100％的解决方案。就像没有cli支持一样，服务器上的更新脚本也无法启动迁移过程。
有人有解决方案或知道可以解决此问题的扩展程序吗？还是可以通过Joomla核心功能（也许需要稍作调整）来处理？
到目前为止，我已经看到了对一个或多个扩展表执行修改的三种可能性
1：在架构表中使用扩展名-版本控制。因此，与该扩展名的模式表中的版本号相比，添加一个新的sql文件，该版本的版本号增加了。还要增加manifest.xml中的版本，然后再次压缩扩展名。 通过扩展->管理->安装重新安装扩展。因此，将执行具有增加的版本号的新sql文件。
2：与上面的要点类似，但是通过joomla更新机制（更新服务器）安装扩展。
3 .：在扩展名的sql / folder中创建一个新的sql文件。新文件不需要版本名称，只需update.sql或其他文件名即可。安装扩展名（在本例中为更新）后，请在update。）方法中的script.php中再次执行此脚本。
第三个可能性可能很有趣。应该可以使用cli命令/函数来触发update（）方法，以便可以通过服务器上的脚本来触发该方法。 但是，如何获取已执行了哪些更新脚本的信息？假设我在sql-folder中有3个更新文件。 update-1.sql，update-2.sql和update-3.sql。 update-1.sql已经执行。因此，我不想再次执行此sql文件-仅执行另外两个。 模式表仅与前两个选项一起使用。我在某处有信息吗？还是我必须管理自己执行了哪些更新脚本的信息？
答案 0 :(得分：2)
与扩展的版本数据库相关的答案取决于这些扩展是否与应用紧密耦合，还是需要可重用到其他应用。
后继情况通常是指每个扩展名访问其自己的自定义表，在这种情况下，您应保持单独的版本控制< / strong>，而不是扩展名。
应用程序版本历史记录可以保存在db_version表中。然后，在每个更新脚本的末尾添加一个插入语句（添加一个增量版本号）。例如
insert into db_version(version,author,description) values(003,'Verna.Collins', 'removing obsolete column');
还提供了对扩展名的数据迁移的应用，还需要维护一个db_version_extensions表，该表保留了版本历史记录分别分别的每个扩展名。例如
'001''extension1'，'Mandy.Aguilar'，'初始版本'
'002''extension1'，'Mandy.Aguilar'，'添加额外的列'
'001''extension2'，'Edna.Potter'，'初始版本'
'002''extension2'，'Elvira.Townsend'，'删除未使用的表'
..etc
每个扩展zip 应该保留初始创建脚本和所有sql-update文件（通常应不干扰与其余 app表 >）。
拉取后，执行文件名版本大于数据库中最后写入的版本号的所有脚本将相对容易。应该为应用和每个扩展单独完成。
现在，如果扩展与应用紧密关联，则意味着扩展可能正在使用/更新应用的表。对于此类型的扩展程序，您可以添加更新作为应用程序更新的一部分。这些扩展甚至可以在相同的仓库上开发，并保留为目录而不是zip文件。
不确定joomla是否支持任何用于自动执行增量数据库更新过程的工具，但是一个不错的工具是flyway，带有用于命令行，maven和graddle的端口。参见：how does flyway work