在我的 SOA 中，我有 2 项服务——用户服务和产品服务。用户和产品都可以用 2 个对象“标记” - 国家和行业。这意味着这两个服务都将有一个连接表，未来的服务也将需要它。如果可能的话，我希望国家和行业的数据库能够标准化并从一个地方进行管理。我能想到几个选择：
我错过了任何好的选择吗？在这 2 个或任何其他建议中，您会选择哪一个，为什么？
您可能想研究Replication。根据您的描述，快照复制似乎是最合适的。您将拥有一个数据库来维护您的公用表（使用专用应用程序或直接 SQL 等），然后您的服务数据库将成为订阅者。SQL Server 将负责在服务器之间复制数据。
您甚至可以拥有公用表的外键（因为它们出现在每个服务数据库中）
这实际上是您的选项 2，但填写了“如何同步主从表”位。
如果您过于担心 User 和 Product 表的引用完整性，我会在多个数据库中保留这些表的只读副本并建立 FK。然后编写一个服务以使所有副本保持最新。
否则，您在选项 1 中提到的轮辐式解决方案可以完成这项工作。但是您需要以编程方式控制对用户表和产品表的数据输入，以建立良好的数据质量。
使用一个包含所有表的数据库，然后打开两个服务到它的连接，编写干净的事务并让 ACID 属性处理任何（不太可能的）问题？
简单、高效、易做。
是否有要求阻止此解决方案工作？
现在，您基本上是在比较简单性与性能（因为您提到引用完整性不是问题）。在选项 1 中，一切都集中定位和管理，它需要额外的网络跃点来提取数据，但您不必担心过时的数据或管理可能有自己问题的多个数据库。如果您的主服务器正常工作，那么它适用于所有人。在选项 2 中，将您的数据存储在本地将提高您的性能，但它会使系统的长期维护复杂化并产生潜在的数据不一致问题（尽管鉴于您的数据是国家和行业，它可能不会经常更改，因此不需要会经常更新）。
我的建议是构建更简单的解决方案（选项 1），然后在需要时调整性能（使用选项 2 或可能的其他解决方案）。在优化性能时，请在添加本地数据库之前查看服务器之间的延迟，您可能能够解决索引或统计信息的问题。
复制和数据缓存是真正有趣的话题之一，但很少是正确的选择。数据库旨在处理共享数据，并且大多数数据库都非常擅长。如果数据满足特定要求，您应该只保留数据的多个副本，例如：
如果您没有特殊要求，请听 Kdansky。把事情简单化。花尽可能多的开发时间为您的用户提供功能......而不是编写数据完整性监视器。