Question

我们正在寻求用liquibase替代各种本地的和手动的数据库部署过程。我们希望最终使用liquibase的数据库上有数十个数据库。许多数据库中已经有数百个对象。

在尝试了liquibase一段时间之后，这就是我想出的一个问题，我想看看是否有人看到任何明显的缺点。

由于某些数据库具有数百个对象，因此我按对象类型分解了databaseChangeLogs。我有一个主要的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">
	<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数据库的ChangeLog看起来像这样：

<?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表中跟踪更改，我使用对象名称作为更改集的ID，并使用JIRA问题作为作者。因此，ID会随着时间的推移保持不变，但是开发人员会在每次更改对象时更新作者。可以随时间更新并重新运行的存储过程，视图等的databaseChangeLogs遵循相同的形式。

有人看到这种方法有什么问题吗？

感谢您的时间！

Answer 1

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

以其他方式，您的更改日志看起来还可以。

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

1 个答案: