无论好坏，我们都有一个依赖于多个数据库的解决方案，这些数据库都引用了一个通用的管理数据库。数据库作为模块的一部分提供，并非所有模块都需要安装（这可能是我们首先拥有多个数据库的原因）。需要管理数据库，但是......所以它会一直存在。
我想为混乱带来一些参照完整性和秩序，但由于 SQL Server 无法执行跨数据库外键而受到阻碍。数据库中没有很多流失，但信息将由（咳咳）非技术用户插入/更新。
我看到的选择是：
a）使用触发器强加伪外键（好的，但有点工作）
b）使用触发器从管理员复制到其他数据库（灾难的明确秘诀）
c) 在代码/DAL 中强加伪外键（与 ORM 不兼容）
d) 不要在 DB 级别担心它，使用良好的 UI 设计来确保没有人做任何愚蠢的事情并限制直接 SQL 访问的访问/屏住呼吸。
坦率地说，我倾向于选择“D”，但我认为我会比我更聪明地寻求意见......
我们有完全相同的问题，坦率地说，这很糟糕。我们发现唯一有效的解决方案是选项 D，并使用业务层来尝试保持同步（包含在事务中等）
假设每个模块都设置为与管理数据库链接，您可以通过为每个模块数据库中的管理表设置视图来简化事情。
We have such a modularity in our products, but our database requirements are merged together during installtion. For example our admin package and product A may be the initial purchase by a client where they install the two modules into database X. If they later buy product B the database component is layered right on top of database X adding in the DRI where necessary.
The only case where I have seen the need for separate databases from a design perspective is when you are drawing a hard line between business units (such as a corporation) at which point the issue is really a type of partitioning. Great Plains Dynamics does this where they have a single administrative database, and multiple corporation databases. However each module in GP for a given corporation resides in that single database.
Of course if you are stuck with separate databases, I would agree that D is the best option.
Depending on your database implementation, often you will be able to link tables from another database (the AdminDB) and have them appear in your various module databases.
In Microsoft Access you can link tables by right clicking, and then choosing an ODBC data source. In Oracle they call it a database link. I'm willing to bet SQLServer has some form of this implementation short of implementing custom replication on a single table.
Once you link in your foreign admin tables to your module databases (or vice versa), then you should be able to define constraints as if the tables were within the same schema.
A second option may be even simpler. What if you used the same schema for all modules and admin database? You know the admin database is present, so simply run the table creation script against that schema. As long as there is no table / view / stored procedure naming conflicts, then it should all work just by changing the dblogin in all modules to match.
您可以在架构上以多种方式解决此问题，以便通过中央服务汇集所有更改，这样它们就不会产生不一致，但无论您愿意为此付出多少努力（并造成瓶颈或单一故障点可能会违反您拥有的其他一些要求）您将无法像使用 FK 约束一样依靠数据库引擎本身来保证执行它。
我经常不得不在跨部门的数据库情况下处理这个问题，因为不同的系统还没有完全集成，或者安全问题需要他们有单独的管理员，所以事情可能会不同步。
在这些情况下，我通常依靠每小时生成的异常报告来检查事物的状态并仅在出现问题时报告。SQL Server 代理作业具有强大的调度功能。我总是使用日志表和 SQLAnswersMail 来生成漂亮的小 HTML 电子邮件（电子邮件中的 URL 链接甚至可以将您带到管理页面以纠正问题）给各种系统管理员，但是有很多方法可以给这只猫剥皮。
您应该实现面向服务的体系结构。系统中的不同服务使用它们的数据库模式运行。然后让您的应用程序独立于任何数据库运行，但让它们针对服务运行。
我想这取决于您的应用程序的重要性。如果该管理数据库出现故障，您是否希望以可能有限的方式继续操作。如果你说，没办法，如果管理员关闭，整个应用程序应该立即停止，而不是到目前为止所说的一切都很好。
如果您说，“哎呀，没有管理数据库仍然可以完成很多工作。” 那么我会问，为什么你认为单向复制如此奇特，以至于它显然是灾难的根源？
制作表格的副本根本不是火箭科学。事实上，它就像复制你的房子钥匙一样简单。母版中的每一个波峰和波谷，都被传送到一个成型坯料的切割轮上。多主复制的神奇之处在于，如果您开始允许远程数据库对来自管理数据的数据进行更改，那么您就开启了一个严肃的设计考虑。
我并不是说这是要走的路，你必须先回答我最初的问题。在那之后，如果你确实想继续运营……不要低估复制的可行性。
我想知道SQL Server 是否有像Oracle 的物化视图这样的特性？这是您使用查询（如视图）定义的对象，但查询的结果存储为表。然后有各种自动刷新的机制。
如果有这样的功能，我建议对每个卫星数据库中的核心表进行物化视图。然后你可以在你的外键中引用它。主要问题是它是否可以足够频繁地刷新以满足您的需求。
我认为有趣的事情.. 是您可以制作数据库的小型 MS Access 副本，在 Access 中强制执行 RI.. 然后升级，Microsoft Access 让您可以选择使用触发器或 DRI.. 我'我很确定 Microsoft Access 将为您编写触发器的核心部分。
当我们讨论这个话题时，我讨厌 MS Access.. 但 Access 的优势之一是您可以针对 QUERY（sql 选择，又名视图）强制执行 RI。我真的希望 MS SQL Server 有相同的功能。