Database design 如何利用多个数据库修复引用完整性 我正在设计一个系统，用于在全国各地生产多个生产基地（所有信息都在一个地点），有可能增加更多。起初，我认为我可以只使用一个数据库。我现在正在重新思考我的原始设计，并倾向于更具可扩展性的解决方案。降低每个数据库/表的大小也很重要

将有一个“主”数据库，其中包含跨越站点概念的信息，然后为每个站点创建一个单独的数据库，其中包含特定于站点的信息

我的难题是如何分离数据。这些数据都相当相关。无论我在哪里做，我都会失去一些参考完整性。我读到的每一篇文章都说要不惜一切代价避免这种情况，我认为这是很好的理由，但我看不出有什么办法可以解决这个问题

我已经研究过触发器，但我认为如果数据库位于不同的服务器上，它们就不起作用了（尽管不确定——我认为Oracle会这样做）。我只限于开源解决方案，所以如果有帮助的话，我会选择MySQL或postgre

是否有人有一些建议来缓解这个问题，或者有其他的设计建议？

MySQL有，但不清楚外键约束是否会在它们之间起作用。我有点怀疑，但扳机应该是

---

否则，你必须将你的参考完整性向上移动一层-进入应用程序。

在不了解你的具体情况的情况下，这有点难以帮助-但这是我的直觉

我猜，您建议的应该放在“主”数据库中的信息可能比每个站点的数据库更稳定（数据更改次数较少）

也许您可以考虑一种解决方案，其中“主”数据库中的数据也存储在每个站点的数据库中。然后，您可以查看某种复制系统，以将对主数据库所做的更改传播到站点数据库

---

这样，您仍然可以在每个站点的数据库中保持引用完整性。

您在谈论多少数据？你真的需要这种架构吗？DBs可以驱动大量的容量

“不要这样做”的警告来自艰苦、痛苦的经历。而且，分布式数据集的维护和管理是一个真正的难题。所以，好好想想怎么做

也许考虑把数据分解成一个操作商店，而不是一个报告仓库或数据仓库，你可以每晚或每周进食（取决于你现在需要什么样的分析报告）。许多运营数据存储不需要那么大

对于仅在后端维护的表（例如，出于数据完整性目的）与那些经常由用户更新和添加到的操作表，这也是一个不同的问题。更多的“静态”表可以被认为是静态的——只是静态的。如果有必要的话，可以通过一个可靠的过程在节点之间更新它们，理想情况下很少

---

一旦您的数据进入“动态”表与“静态”表，分区就更容易了，因为您的静态数据可以根据需要（从根实例）单独掌握和复制，而分区存储是用于反馈后端数据仓库和报告系统的真理的单一来源。因此，几乎不需要实际的复制，但更多的是一个“它在哪台机器上”的问题，可以很容易地自动化。

如果您理解正确，您希望（可能）使用触发器检查每次插入/更新/删除是否在远程数据库上保持了引用完整性

如果是这样的话，我认为您应该避开这一点，我只是认为性能开销是一个太大的问题。特别是如果您希望解决方案是可伸缩的

我会担心数据是如何插入的，对此我会非常严格，你的应用程序逻辑应该涵盖这是一个高层次的细节。您可以运行每周报告，查看哪些数据不正确，以及为什么数据插入不正确等等，但我认为，如果您的应用程序运行正确，那么多数据库引用完整性将很难实施

但别误会我的意思，我百分之百支持将数据保持在可靠、健壮的状态，但有时这并不总是可行的

---

但正如前面所说，如果没有更多关于解决方案的信息，就很难给出建议……：）

让我看看是否可以为问题领域提供更好的概要：

希望创建一个“企业”解决方案，其中n个生产站点的数量将增加

我们处理数据以创建web和打印文档

系统将管理流程，以将数据文件从提交（通过集中式网站）传送到打印机或web或两者

每个生产站点都有自己的客户等。所有这些信息都将存储在数据库中。该信息的大部分管理将在中心站点进行

由于所用软件的许可限制，我们在一台服务器上处理所有数据

因此，将有一个守护进程来查看队列（在数据库中）并处理作业。流将由数据库中的状态列控制，以便其他进程知道它在进程中的位置

海量数据的来源是我们的网络工具。我们需要为我们为web生成的每个文档存储搜索索引。这个很快就变大了。这些记录不会永远保留，但至少在大多数情况下会很大（估计有5亿行）

我认为，要解决表大小问题，可以使用单独的数据库，也可以使用在不同服务器上分离生产站点的功能

问题是，我不知道什么时候会收购另一个网站，或者它会有多大

我想我想把可伸缩性问题扼杀在