数据库功能分解的模式？

Question

我们有以下问题。我们的企业应用程序在MySQL中有一个数据库，看起来它的结构变得太复杂 - 超过100个表（它已经开发了7年）。

但是，大多数表与任何其他表都没有任何关系。每个人都使用一些常用表（字典）（大约20个这样的表），但这就是全部。问题出现了如何使这个数据库更快更可靠。

我读了很多关于数据库分解的内容。也就是说，您将与不同域相关的表放在不同的数据库中。例如，与运单和其他纸张相关的任何内容都放在名为Papers的数据库中，与客户及其订单相关的任何内容都放在名为Clients的数据库中，依此类推。

这里有两个问题：

• 用户应将企业应用程序视为在单个域上执行操作。开发人员必须以某种方式更改使用数据库的核心，以便它可以处理多个数据库。
• 常见表格出现问题。它们必须保存在单个数据库中，并且在分解后不能在所有数据库中复制。因此，我们如何进行查询SELECT * FROM A JOIN B，A和B是否在不同的数据库中（在不同的服务器上）？

这两个问题实际上都解决了同样的问题 - 是否有任何常见的企业模式（如GoF）来解决这个问题？我对适合Java EE的模式特别感兴趣。

Answer 1

我不一定要将表组移动到他们自己的数据库中 - 这将使系统变得更加复杂，现在您还有其他问题，例如同步多个数据库的备份。 IMO 100表并不笨重。

但是，如果有商业驱动的需要将系统（和数据库）的功能分成多个系统，那么一定要这样做。显然，这需要对系统进行重大更改甚至重写。

Re：Waybill，Invoice等，遗憾的是，MySQL没有像其他RDMS那样实现Schema，就像MS SQL Server一样。 您可以通过向表添加前缀（PaperWaybill，PaperInvoice等）来模拟模式固有的命名空间。

但是，现在更改表名可能是不明智的，因为您的系统已经生产了7年，并且确定所有依赖项可能很棘手 - 例如可能有几个应用程序，报告，工作等都访问这些表。

IMO你需要了解为什么关系太少的核心原因。 可能存在关系，但FOREIGN KEYS被删除，例如为performance reasons。如果这妨碍了您绘制系统图或阻止ORM代码生成器等工具创建关系的能力，您可以将PROD数据库恢复到DEV环境并将外键添加回DEV。同时，您可以了解数据质量 - 例如FK约束。