如何正确管理复杂的数据库结构？

Question

假设您有多个使用相同数据库的系统 - 每个系统使用多个方案（有时与另一个方案相同）。这些方案的结构有点大而复杂。

现在，你怎么可能管理这样的计划结构？显然使用某种“配置” - 最简单的是SQL脚本，但更合理的解决方案是可以轻松转换为SQL的XML，或其他一些可读的解决方案（例如，JPA的XML或Annotations）。

但是，这个解决方案会导致一个问题，即您无法确切地判断您的配置是否与数据库方案的结构完全匹配。你不能说这两个是否同步。他们为什么不呢？好吧，在如此大的结构中会有很多变化，你不会总是记得在你改变方案后保存/提交你的配置，或者你可能保存/提交它，但最终没有改变方案中的任何内容都忘记撤消对配置的更改。

更重要的是，另一个问题（不是由配置引起的，但也没有解决）是版本控制。我没有看到任何管理数据库方案版本的好方法（比如我们上次的更改会导致3个系统崩溃 - 不好，如何“回滚”？）。

想法？ THX。

Answer 1

这个问题很模糊，但我相信LiquiBase（www.liquibase.org）的发明是为了解决你所描述的各种问题。

Answer 2

虽然有一些工具可以检查两个数据库之间的差异，但这些工具用于推广产品是很危险的。通常有些物品尚未准备好发送给prod，工具无法知道这一点。这更有可能发生在几个不同应用程序使用的大型企业类型数据库中。

数据库代码应该像任何其他代码一样对待。它应该在脚本的源代码控制中，并按发布组织。如果没有源代码控制的脚本来正确发布，没有什么可以做的。