如果关系表可能驻留在多个数据库中，是否有必要以不同的方式设计关系表？答案

【问题标题】：Is it necessary to design relational tables differently if they might reside in several databases?如果关系表可能驻留在多个数据库中，是否有必要以不同的方式设计关系表？
【发布时间】：2009-12-28 22:32:49
【问题描述】：

我正在为一个应用程序设计数据库模式，由于单个用户可能创建的条目数量，该应用程序将来可能涉及将一些表分散到多个数据库中。我目前正在设计表关系，牢记常见的最佳实践，但我没有考虑服务器架构、表分区、分片、主/从等——在创建模式时是否有必要考虑这些事情，或者这是我想得太远的情况之一吗？到目前为止，我所做的唯一决定是在应用程序级别管理任何外键约束，以便我可以更轻松地将表移动到不同的数据库。

【问题讨论】：

在应用程序中管理外键是一个非常糟糕的选择。数据通常从应用程序以外的来源进入数据库。这种方法最终会出现数据完整性问题。确实是个坏主意。
如果您有数据从应用程序以外的来源进入数据库，那么您需要担心更大的问题。
哈尔，客气地说是愚蠢的。数据来自其他供应商的导入，来自大规模更新，而不仅仅是应用程序。如果你不为这些事情做计划，你就会遇到问题。但是继续设计糟糕的数据库，这就是我得到报酬来修复它们的原因。
是的，但是数据库是为提供数据而设计的。不绑定到 1 个主应用程序。现在可能是这样，但可能会出现要求多个应用程序连接到数据的需求。如果您必须担心 2 个或更多应用程序中的应用程序限制，那将成为一场噩梦。我认为这是一场噩梦！
进口？海量更新？你还在谈论应用程序。听说过针对 XSD 的验证吗？同样，如果您只是让原始数据进入数据库而没有任何应用程序管理，那么您将遇到更大的问题。让数据库成为所有数据进出的单点故障是无知的——没有人设计这样的系统。

标签： mysql database-design schema

【解决方案1】：

听起来您仍处于逻辑设计阶段——也许对象模型会更方便。我认为您过早地进入关系设计。一些数据可能很适合具有系统强制完整性约束的关系数据库。其他东西可能更适合 RESTful 服务、内存缓存或文件系统集群。如果您的问题不需要它们，请不要承诺设计功能。不要忘记 ACID 事务是一个设计特性。 ;)

有一些缩放关系设计的示例。 WordPress 有一个单一的关系设计，但运行 wordpress.com 的令人难以置信的分片 WordPress mu 共享 99% 的代码。其他网站（这个！）在关系设计上支持庞大的用户社区。p>

我认为假设您可以忽略性能并稍后添加它是错误的。忽略性能并计划将其丢弃？这是一个合理的方法。

【讨论】：

【解决方案2】：

是的，您应该考虑针对生产中数据库的预期大小进行性能设计。设计中的微小变化可以对数据库的扩展程度产生巨大影响。数据库一旦拥有数百万条记录就不容易重构。您还应该在设计中考虑数据安全性和数据完整性。数据完整性只能在数据库级别成功地得到保障，试图在应用程序中做到这一点是愚蠢和短视的。

您还应该考虑需要哪些元数据（如果有）。你需要审核吗？您是否需要用于复制的 GUID？您需要知道何时插入记录吗？您打算归档吗？

【讨论】：