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

假设您有多个系统使用相同的数据库 - 每个系统使用多个方案（有时与其他方案相同）。这些方案的这种结构有点大而复杂。如何正确管理复杂的数据库结构？

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

尽管这个解决方案导致了一个问题，即您无法确切地知道您的配置是否完全匹配数据库结构。你不能说这两个是否同步。他们为什么不呢？那么，在这样一个庞大的结构中，将会有很多改变，并且在改变方案之后，你不会永远记得保存/提交你的配置，或者你确实保存/提交了它，但最终没有改变计划中的任何内容并忘记取消对配置的更改。

不仅如此，另一个问题（不是由配置引起的，而是由它来解决）是版本控制。我没有看到管理DB方案版本的好方法（比如说我们最后的修改会导致3个系统崩溃 - 不好，如何“回滚”？）。

想法？谢谢。

来源

2010-06-11 Eyal Roth

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

来源

2010-06-11 21:06:08

简要阅读了这个库之后，它似乎有助于管理版本控制（也在几个开发者之间），但是它如何处理同步问题呢？该库可以查看我的配置并查看数据库方案，并告诉我它们之间有什么区别，甚至可以生成能够像现在一样反映数据库结构的配置？ – 2010-06-11 22:38:14

是的。有点。数据库本身会跟踪哪些更新日志已经运行，并能够根据其现有模式生成更改日志：http://www.liquibase.org/manual/generating_changelogs。 – 2010-06-12 00:10:20

虽然有工具可以检查两个数据库之间的差异，但这些使用这些工具来促销产品是非常危险的。通常还有物体还没有准备好发送到产品，一个工具将无法知道这一点。这种情况更可能发生在由多个不同应用程序使用的大型企业类型数据库中。

数据库代码应该像其他代码一样对待。它应该在脚本中进行源代码管理，并按照发行版进行组织。没有适当版本的源代码控制脚本，没有什么可以推动的。

来源

2010-06-15 21:31:05 HLGEM

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

回答

相关问题