Flyway 是否适合在支持多个数据库的应用程序中实现?
我们不知道我们的客户正在使用什么——可能是 MySQL、Postgres 或 Oracle。我们还可以使用Flyway为新版本的应用程序迁移数据库吗?
Is Flyway suitable for implementation in an application that will support multiple databases?
We don't know what our customers are using - could be either MySQL, Postgres or Oracle. Can we still use Flyway to migrate the database for new versions of the application?
发布评论
评论(2)
如果您的问题是:Flyway 是否在其支持的数据库中提供DDL 抽象层,答案是否。
这是一个有意识的设计决策,以确保底层数据库的全部功能可用,而不仅仅是迁移工具支持的最小公分母。
对于您的用例,您可以为不同的数据库提供不同的迁移脚本。但它们应该非常相似。
如果您不希望重复迁移脚本并且可以接受最小公分母方法,请查看LiquiBase 可能更适合您的用例(如果您可以接受 XML)
if your question is: does Flyway provide a DDL abstraction layer across the databases it supports, the answer is no.
This was a conscious design decision, to make sure the full power of the underlying database is available and not just the smallest common denominator supported by the migration tool.
For your use case, you could either provide different migration scripts for the different databases. They should be very similar though.
If you do not wish to potentially duplicate the migration scripts and can live with the smallest common denominator approach, have a look at LiquiBase which might be a better fit for your usecase (if you can live with the XML)
您可以使用 jOOQ 的解析连接,它包装您的目标 JDBC 连接,并且能够将您的输入 DDL 转换为任何目标方言(如果它不是太花哨且不是特定于供应商的)。 Flyway 不会知道而且也不必知道此转换 JDBC 代理。可以在此处查看 SQL 翻译器 的在线版本。例如,如果您的输入 SQL 是 MySQL 特定的:
输出可能是:
免责声明:我为 jOOQ 背后的公司工作。
You could use jOOQ's parsing connection, which wraps your target JDBC connection and is capable of translating your input DDL to any target dialect (if it's not too fancy and vendor specific). Flyway wouldn't be aware of this translating JDBC proxy, and wouldn't have to be. The online version of the SQL translator can be seen here. For example, if your input SQL is a MySQL specific:
The output could be:
Disclaimer: I work for the company behind jOOQ.