1

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

  1. 将国家、行业和其他共享数据库保留在自己的服务器上，并允许外部只读连接，同时操作数据必须由一个应用程序完成，其唯一目的是管理该数据。
  2. 将这些表的副本保存在服务本地的数据库中，并让它们充当从表。主表将由管理该数据并将更新推送到这些从表的应用程序维护。

我错过了任何好的选择吗？在这 2 个或任何其他建议中，您会选择哪一个，为什么？

4

5 回答 5

1

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

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

这实际上是您的选项 2，但填写了“如何同步主从表”位。

于 2011-01-14T15:20:24.457 回答
1

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

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

于 2011-01-14T15:05:21.253 回答
0

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

简单、高效、易做。

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

于 2011-01-14T14:58:16.713 回答
0

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

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

于 2011-01-29T22:44:48.673 回答
0

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

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

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

于 2011-01-19T06:02:27.060 回答