我应该如何处理需要被多个应用程序引用的共享数据库？

Question

在我的SOA中，我有2项服务 - 用户服务和产品服务。用户和产品都可以“标记”2个对象 - 国家和行业。这意味着两个服务都将具有连接表，并且未来的服务也将需要它。我希望国家和行业数据库是标准的，并尽可能从一个地方进行管理。我能想到几个选项：

1. 保持国家，行业和 它自己的其他共享数据库 服务器并允许外部只读 操纵时的连接 数据必须由一个人完成 应用程序的唯一目的是管理 那个数据。
2. 将这些表格的副本保存在 服务的本地数据库，以及 让他们充当奴隶表。该 主表将由。维护 管理该数据的应用程序 推出对这些奴隶的更新 表。

我错过了任何好的选择吗？在这两个或任何其他提议中，你会选择哪个以及为什么？

Answer 1

如果您过分担心User和Product表的参照完整性，我会在多个数据库中保留这些表的只读副本并建立FK。然后编写单个服务以使所有副本保持最新。

否则，您在选项1中提到的hub-spoke解决方案可以完成这项工作。但是，您需要以编程方式控制数据输入到用户和产品表，以建立良好的数据质量。

Answer 2

您可能需要查看Replication。根据您的描述，快照复制似乎是最合适的。您将拥有一个数据库来维护公共表（使用专用应用程序，或直接SQL，或其他），然后您的服务数据库将成为订阅者。 SQL Server将负责在服务器之间复制数据。

您甚至可以在公共表中使用外键（因为它们出现在每个服务数据库中）

---

这实际上是你的选择2，但是填写了“如何同步主表和从表”。

Answer 3

对所有表使用一个数据库，然后打开两个服务的连接，编写干净的事务并让ACID属性处理任何（不太可能的）问题？

简单，高效，易于操作。

是否有要求阻止此解决方案工作？

Answer 4

复制和数据缓存是谈论真正有趣的事情之一，但很少是正确的选择。数据库旨在处理共享数据，大多数都非常擅长。如果数据满足特定要求，则应保留多个数据副本，例如：

• 服务实例部署到多个站点之间连接不良或不可靠的位置。
• 在非常高的负载下的性能（通常可以通过购买正确的硬件来解决）。

如果您没有特殊要求，请听听Kdansky。把事情简单化。花费大量的开发时间为用户提供功能......而不是编写数据完整性监视器。

Answer 5

现在您基本上将简单性与性能进行比较（因为您提到参照完整性不是问题）。在选项1中，所有内容都位于中心位置并进行管理，它需要额外的网络跃点来提取数据，但您不必担心陈旧数据或管理可能有其自身问题的多个数据库。如果您的主服务器工作，那么它适用于每个人。在选项2中，在本地存储您的数据将提高您的性能，但它会使系统的长期维护复杂化并产生潜在的数据不一致问题（尽管鉴于您的数据是国家和行业，它可能不会经常更改，因此它不需要经常更新）。

我的建议是构建更简单的解决方案（选项1），然后如果需要调整性能（使用选项2或可能的其他解决方案）。在调整性能时，请在添加本地数据库之前查看服务器之间的延迟，您可以使用索引或统计信息来解决问题。