如何正确管理复杂的数据库结构？
假设您有多个系统使用相同的数据库 - 每个系统都使用多个方案（有时彼此相同）。这些方案的这种结构有些非常庞大和复杂。
现在，您如何管理这样的计划结构？显然使用某种“配置” - 最简单的是 SQL 脚本，但更合理的解决方案是可以轻松转换为 SQL 的 XML，或其他一些可读的解决方案（例如，JPA 的 XML 或注释）。
但是，此解决方案会导致一个问题，即您无法真正判断您的配置是否与数据库方案的结构完全匹配。你不能说这两者是否同步。他们为什么不呢？好吧，在这么大的结构中会有很多变化，并且在更改方案后您不会总是记得保存/提交您的配置，或者也许您确实保存/提交了它，但最终没有更改方案中的任何内容都忘记撤消对配置的更改。
不仅如此，另一个问题（不是由配置引起的，但也不是由配置解决的）是版本控制。我没有看到任何管理数据库方案版本的好方法（假设我们最后的更改使 3 个系统崩溃 - 不好，如何“回滚”？）。
还有想法？谢谢。
Let's say you have several systems using the same DB - each uses several schemes (sometimes same as the other). This structure of these schemes is somewhat very big and complicated.
Now, how could you possibly manage such scheme structure? Obviously using some sort of "configuration" - the simplest would be SQL scripts, but a more reasonable solution would be XMLs which can be easily converted into SQL, or some other readable solution (for example, JPA's XMLs or Annotations).
This solution though, causes a problem where you can't really tell if your configuration matches the structure of the DB schemes exactly. You can't say if those two are synchronized. Why wouldn't they? Well, in such big structure there are going to be many changes, and you won't always remember to save/commit your configuration after you've altered the schemes, or maybe you did save/commit it, but eventually didn't altered anything in the schemes and forgot to undo the changes to the configuration.
More than that, another problem (not caused by the configuration, but isn't addressed by it either) is versioning. I don't see any good way of managing the DB schemes versions (say our last alteration makes 3 systems crash - not good, how to "rollback"?).
And thoughts? thx.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
这个问题很模糊，但我相信 LiquiBase (www.liquibase.org) 的发明就是为了准确解决你所描述的各种问题。
The question is quite vague, but I believe that LiquiBase (www.liquibase.org) was invented to solve exactly the sorts of problems you're describing.
虽然有一些工具可以检查两个数据库之间的差异，但使用这些工具来升级产品是危险的。通常，有些对象尚未准备好发送到产品，工具无法知道这一点。在由多个不同应用程序使用的大型企业型数据库中，这种情况更有可能发生。
数据库代码应该像任何其他代码一样对待。它应该位于脚本的源代码控制中并按版本组织。如果没有用于正确发布的源代码控制脚本，则任何产品都无法进行生产。
While there are tools to check the differneces between two databases, these are dangerous to use to promote things to prod. Often there are objects not yet ready to be sent to prod, a tool would have no way to know this. This is even more likely to happen in a large enterprise type database used by several differnt applications.
Database code should be treated like any other code. It should be in source control in scripts and organized by release. Nothing goes to prod without a source controlled script for the proper release.