使用 MS Sync Framework 2.0，我怎样才能最好地处理相关表？答案

【问题标题】：With MS Sync Framework 2.0, how can I best handle related tables?使用 MS Sync Framework 2.0，我怎样才能最好地处理相关表？
【发布时间】：2011-01-18 08:46:49
【问题描述】：

同步框架逐个表同步数据，但我的实体在相关父子表集之间进行了规范化。这给我的应用程序带来了问题，其中父行可能会出现在要处理的服务器上，但子行可能不会出现几秒钟。如果我的客户端应用程序和服务器之间存在连接问题，则子行可能会在一段时间内不出现。

如何设计我的应用程序来处理与父表分开同步的子表？

我正在研究的特定场景是在服务器上接收来自后端系统的工作订单，然后使用平板电脑或 PDA 将其分发给现场工程师。这些工作订单是可能涵盖六张表的大型复杂实体。工程师完成工作，同步结果，服务器将完成的工单返回给后端系统。

下面是我目前的一些想法。

【问题讨论】：

标签： c# .net synchronization microsoft-sync-framework

【解决方案1】：

使用同步框架，将相关表添加到它们自己的同步组中。例如。将 OrderHeader 和 OrderDetail 表添加到它们自己的名为 Orders 的同步组中。

除非直接相关，否则不要将任何其他内容放在同步组中。

然后同步事务中的每个同步组。这样，您就可以保证同步或不同步所有表...

请询问您是否需要有关此过程的更多详细信息。

【讨论】：

听起来可行，但如何扩展？同步框架是否仍会同步所有订单，然后是所有订单详细信息？如果我有 100 个新订单，每个订单包含 100 件商品怎么办？如果99号出现错误，会不会全部回滚？
这个答案没有解决逐表同步的固有问题：如果我必须同步 20 个相关表怎么办？我是否在一个事务中同步整个数据库？如果我将多个表放在一个事务中，我会使事务运行时间更长。如果超时，我将无法同步任何内容。 -1.
在构建您打算在其中进行一些同步的应用程序时，您必须在设计应用程序数据时考虑到这一点。根据您想要进行同步的原因的本质。即，您有时会断开连接，或者某个链接失败（例如 3g 链接）。如果您将应用程序设计为需要同时拥有 20 个表，那么是的，您必须设计一个长时间运行的事务，并且，正如您所说的那样，它失败了，那么您需要全部回滚.. 出路是构建一个日志文件类型系统，您在其中写入更改，例如通过触发器到单个表，然后同步..
..并在本地应用更改。但是，对于并非以易于断开连接的方式构建的设计，这些确实是解决方法。虽然同步可以让您获得最终的一致性，但这确实意味着并非所有内容都始终是最新的。同步框架允许您按照我的描述对事物进行分组，但如果该组太大以至于不切实际，那么真正需要查看数据模型的设计......
尽管曾经对这个答案投了反对票，但我现在认为这比我将水推上山的任何其他想法都要好。应用程序应该围绕 Sync Framework 将做什么和不做什么来设计。使用批处理来支持更多的行，但尽量限制表之间的依赖关系。

【解决方案2】：

设计应用程序，使数据出现在不同时间都无关紧要。该应用程序将显示或操作当时可用的任何数据。如果稍后显示更多数据，它也会显示。

优点：

这可能是一种灵活而稳健的数据处理方式，并且不依赖于大量复杂的同步代码。

缺点：

如果用户认为他们正在查看完整的任务或工作订单或其他任何内容，但稍后会出现额外的部分，这可能会让用户感到困惑。
如果数据从用户同步到服务器以发送到其他后端系统，则该系统可能不支持部分提交。

【讨论】：

【解决方案3】：

非规范化一切。创建一个数据库视图，将相关表扁平化为单个连接的结果集，或者首先将数据存储在一个大表中。配置 Sync Framework 以同步该表，通过视图中的“最左侧”键对其进行批处理，该键应该是层次结构中根表的主键。现在，客户端上的每个事务都包含对单个实体所做的所有更改。

优点：

可以完全在数据库中实现。
无需替换 Sync Framework 的任何部分。
只要您注意视图的构建和过滤方式以及基础表的索引方式，就可以很好地扩展到大量行。

缺点：

放弃数据库规范化可能会被认为是不好的。
可能无法很好地扩展到需要大量连接的大量表和列。
还必须汇总变更跟踪数据。
如果使用视图，则必须创建触发器以使其可更新。

【讨论】：

【解决方案4】：

我可以自定义 Sync Framework 以使其尊重数据库关系。当自定义 SyncAdapter 遇到有更改的行时，它可以遍历数据库架构中的子关系以获取相关行中的任何更改。这些更改将全部添加到同一数据集并作为单个事务同步。

优点：

从数据完整性的角度来看，这似乎是最好的解决方案。我可以确定一个特定的实体要么包含来自客户端的所有可用更改，要么不包含任何更改。
我不需要更改我的实体或以任何特殊方式向自定义适配器描述它们 - 它所需的所有信息都可以从我已经拥有的数据库关系中获得。
我不需要对我的数据库架构做任何特别的事情 - 我几乎可以将我的代码指向任何数据库并且它会正常工作。

缺点：

以这种方式自定义同步框架可能需要大量工作，并且需要详细了解框架的内部结构。
自定义适配器需要检测和处理循环数据库关系。

【讨论】：

【解决方案5】：

带有校验和的东西呢？每次应用程序对实体进行更改时，它都会根据实体的最新内容计算哈希并将其保存在父行中。当应用程序读取实体时，它可以重新计算哈希。如果当时可用的数据与存储在实体中的哈希不匹配，则应用程序知道需要进行更多同步。

优点：

可能是对应用程序域模型的相当直接的更改，不涉及更改 Sync Framework 的内部结构。

缺点：

应用程序每次进行更改时都需要将与实体相关的所有行读入内存。
如果应用程序必须支持对来自多个客户端的同一实体的更新，这将变得更加复杂。
需要仔细计划在每个方向上同步哪些更改以及何时计算相应的哈希值。根据您的数据，您可能需要多次同步相同的表。
为一个应用定制；你不能把相同的代码应用到其他东西上。

【讨论】：

【解决方案6】：

评论框内没有足够的空间来表达我的想法：

同步主实体而不是关系数据？我不知道我们是否可以使用 Sync Framework 来做到这一点……也许可以实现自定义提供程序？

交易仍然存在问题。让我们举一个愚蠢的例子，你有账户，每个账户都是一个主实体。

数据库A

BeginTransaction
    Substract $500 from account 1
    Add $200 to account 2
    Add $300 to account 3
EndTransaction

数据库B

BeginTransaction
    Substract $100 from account 1
    Add $100 to account 4
EndTransaction

同步时，您会检测到 1 上的冲突，但不会检测到 2、3 和 4 上的冲突。使用此示例，您可以详细说明合并策略，但情况并非总是如此。

【讨论】：