在单独的数据库之间建立关系是不好的做法吗？

Question

我正在与具有多个数据库的客户合作。有几个master级别数据库与instance级别数据库（特定于应用程序的 DB）有关系。从instanceto的关系master是整数值，表示master. 中的视图和存储过程instances设置为master通过这些存储的键加载数据。

显然，没有真正的参照完整性，但这是不好的做法还是数据应该驻留在instance数据库的只读表中？

Answer 1

唯一的问题是没有真正方便的方法来强制执行这些关系。您可以使用大量触发器，或者将主表存储在每个实例数据库中，然后简单地将所有这些作为元数据公开给主表，也许使用视图。

我认为，最大的缺点与保持数据准确和同步有关，至少在我脑海中的三个场景中（即使您使用触发器，所有这些仍然可能是一个问题）：

• 不正确协调的跨数据库事务- 例如，一个事务向 master 添加一个新行，将身份交给另一个事务，然后第一个事务回滚。
• 从单个数据库故障中恢复- 数据库崩溃，您必须恢复到某个时间点，这可能是在其他数据库中的其他成功事务完成之前。这可能意味着如果实例数据库必须恢复到更早的时间，它会丢失 master 期望的行；如果 master 必须恢复，则所有实例数据库都可能具有 master 中不存在的值。
• 一般备份一致性- 如果您需要灾难恢复，您将很难保持所有完整备份和日志备份在事务上与某个时间点保持一致。文件系统快照对此无济于事，甚至可用性组也不保证单个可用性组中数据库的跨数据库事务一致性。如果您遇到灾难并且需要将数据库恢复到新系统，则无法确保它们在事务上是一致的。

尽管如此，我一直并将永远是将租户分离到他们自己的数据库中的粉丝，我承认中央数据库存在风险 - 但这是必要的。

（顺便master说一句，你应该为你的数据库使用 master / instance 以外的名称。在 SQL Server 中肯定有一个明确的含义，即使阅读我上面自己的话，它们也可能是模棱两可的。同样的instance。在以前的生活中，我运行了一个多-租户系统，我们称之为中央数据库Control和租户数据库，嗯，Tenants。）