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

我正在与一个具有多个数据库的客户端一起工作。有多个master级别数据库，这些级别数据库具有从instance级别数据库（特定于应用程序的DB）返回的关系。从instance到的关系master是整数值，代表.NET中表的主键master。设置中的视图和存储过程以通过这些存储的键instances从中加载数据master。

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

唯一的问题是，实际上并没有一种简便的方法来执行这些关系。您可以使用一系列触发器，也可以将主表存储在每个实例数据库中，然后仅使用视图将所有表作为元数据公开给主数据库。

我认为，最大的缺点与保持数据的准确性和同步性有关，至少在我头上的至少三种情况下（即使使用触发器，所有这些仍然是个问题）：

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

话虽这么说，我一直并且永远都是将租户分离到自己的数据库中的狂热者，我承认中央数据库存在风险-但是这是必要的。

（顺便说一句，你应该比主/实例之外的其他数据库使用的名字。master在SQL Server中肯定有一个明确的含义，甚至读我自己的话上面，他们可能是不明确的。同样的instance，在以前的生活中，我跑了一个多-tenant系统，我们称为中央数据库Control和tenant数据库，Tenants。）

如果您遵循的是微服务之类的架构，那么必须能够跨多个自主服务关联数据，而每个自主服务均具有自己的数据存储。每个服务将理解，传统上在单个数据库事务中执行的业务流程现在可能会运行更长的时间。