我的 databaseChangeLog 层次结构有意义吗？

Question

我们希望用 liquibase 取代各种自行开发和手动的数据库部署流程。我们有几十个我们希望最终使用 liquibase 的数据库。许多数据库中已经有数百个对象。

在试用 liquibase 一段时间后，这就是我想出的，我想看看是否有人发现任何明显的缺点。

由于一些数据库有数百个对象，我按对象类型分解了 databaseChangeLogs。我有一个主数据库更改日志文件，如下所示：

<?xml version="1.0" encoding="UTF-8"?>
<databaseChangeLog xmlns="http://www.liquibase.org/xml/ns/dbchangelog"
                   xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
                   xmlns:ext="http://www.liquibase.org/xml/ns/dbchangelog-ext"
                   xsi:schemaLocation="http://www.liquibase.org/xml/ns/dbchangelog http://www.liquibase.org/xml/ns/dbchangelog/dbchangelog-3.1.xsd http://www.liquibase.org/xml/ns/dbchangelog-ext http://www.liquibase.org/xml/ns/dbchangelog/dbchangelog-ext.xsd">
 <include file="migrations/_tables.xml" relativeToChangelogFile="true"/>
 <include file="migrations/_triggers.xml" relativeToChangelogFile="true"/>
 <include file="migrations/_views.xml" relativeToChangelogFile="true"/>
 <include file="migrations/_stored_procedures.xml" relativeToChangelogFile="true"/>
</databaseChangeLog>

因此，当迁移运行时，它将首先在 _tables.xml 中进行架构更改，然后在 _triggers.xml 中触发，依此类推。

_triggers.xml databaseChangeLog 如下所示：

<?xml version="1.0" encoding="UTF-8"?>
<databaseChangeLog xmlns="http://www.liquibase.org/xml/ns/dbchangelog"
                   xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
                   xmlns:ext="http://www.liquibase.org/xml/ns/dbchangelog-ext"
                   xsi:schemaLocation="http://www.liquibase.org/xml/ns/dbchangelog http://www.liquibase.org/xml/ns/dbchangelog/dbchangelog-3.1.xsd http://www.liquibase.org/xml/ns/dbchangelog-ext http://www.liquibase.org/xml/ns/dbchangelog/dbchangelog-ext.xsd">
 <changeSet id="tr_names_delete" author="PROD-1235" runOnChange="true" > <sqlFile path="triggers/tr_names_delete.sql" relativeToChangelogFile="true" /> </changeSet>
 <changeSet id="tr_names_insert" author="PROD-1235" runOnChange="true" > <sqlFile path="triggers/tr_names_insert.sql" relativeToChangelogFile="true" /> </changeSet>
 <changeSet id="tr_names_update" author="PROD-1235" runOnChange="true" > <sqlFile path="triggers/tr_names_update.sql" relativeToChangelogFile="true" /> </changeSet>
</databaseChangeLog>

我为每个对象设置了一个更改集。这样我就可以在 DATABASECHANGELOG table 中跟踪随时间的变化，我使用对象名称作为变更集的 ID，并使用我们的 JIRA 问题作为作者。因此 ID 会随着时间的推移保持不变，但开发人员会在每次更改对象时更新作者。可以随时间更新和重新运行的存储过程、视图等的数据库更改日志遵循相同的形式。

有人发现这种方法有什么问题吗？

感谢您的宝贵时间！

Answer 1

如果您使用不同的类路径执行变更日志，请将 logicalFilePath 添加到您的变更日志以在数据库变更日志中具有相同的路径
我不会将 runAllways=true 用于程序。想象一下你想 return 到以前版本的情况。最好（恕我直言）只附加更改日志并使用 rollback 指向以前的版本。
有时类型之间可能存在依赖关系（触发器中的视图、过程中的函数等）。为此，您在主更改日志中指定的执行顺序将不起作用。但是可以将这些更改添加到单独的更改日志中（例如 uncategorized-changes.xml）。
如果你想支持多种数据库类型，请做好准备，你将需要对某些功能进行一些配置（例如 sysdate vs now() vs current_date...） .为此准备一些文件，您可以在其中将这些配置定义为属性，然后将该文件包含在您的主更新日志中。

在其他方面，您的变更日志看起来还不错。

我的 databaseChangeLog 层次结构有意义吗？

Does my databaseChangeLog hierarchy make sense?

liquibase