1

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

但是，大多数表与任何其他表根本没有任何关系。有一些人人都使用的通用表（字典）（大约二十个这样的表），但仅此而已。问题出现了如何使这个数据库更快、更可靠。

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

这里我们有两个问题：

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

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

4

1 回答 1

0

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

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

Re: 运单、发票等不幸的是，MySQL 没有像 MS SQL Server 那样实现其他 RDMS 的Schema 。您可以通过向表（PaperWaybill、PaperInvoice 等）添加前缀来模拟模式固有的命名空间。

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

IMO，您需要深入了解为什么关系如此之少的核心原因。然而，有可能存在的关系FOREIGN KEYS被删除，例如出于性能原因。如果这妨碍了您绘制系统图的能力，或者阻止诸如 ORM 代码生成器之类的工具创建关系，您可以将 PROD 数据库恢复到 DEV 环境并将外键添加回 DEV。同时，您会了解数据的质量——例如 FK 约束。

于 2012-11-12T11:48:36.457 回答