使用MS Sync Framework 2.0,我如何才能最好地处理相关表?

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

不要在同步组中放置任何其他内容,除非它直接相关。

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

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

• 如果用户认为他们正在查看一个完整的任务、工作单或其他任何东西,那么可能会让他们感到困惑,但后面会出现额外的部分。
• 如果数据从用户同步到服务器并发送到其他后端系统,则该系统可能不支持部分提交。

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

• 可以完全在数据库中实现。
• 只要仔细考虑视图的构造和过滤方式以及底层表的索引方式,就可以很好地扩展到大量行。

• 放弃数据库规范化可能被认为是不好的。
• 如果使用视图,则必须创建触发器以使其可更新。

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

• 从数据完整性的角度来看,这似乎是最好的解决方案。我可以确定一个特定的实体要么包含来自客户端的所有可用更改,要么不包含任何更改。
• 我不需要更改我的实体,也不需要以任何特殊的方式向自定义适配器描述它们——它所需要的所有信息都可以从我已有的数据库关系中派生出来。
• 我不需要对我的数据库模式做任何特殊的操作——我几乎可以将我的代码指向任何数据库,它就可以正常工作。

欺骗:

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

有校验和的东西怎么样?每次应用程序对实体进行更改时,它都会根据实体的最新内容计算一个哈希值,并将其保存在父行中。当应用程序读取实体时,它可以重新计算散列。如果当时可用的数据与实体存储的哈希不匹配,则应用程序知道还有更多的同步要做。

赞成的意见:

• 可能是对应用程序的域模型的一个相当直接的更改,而不涉及更改同步框架的内部结构。

• 每次进行更改时,应用程序都需要将与实体相关的所有行读取到内存中。
• 如果应用程序必须支持来自多个客户端的对同一实体的更新,那么这将变得更加复杂。
• 需要仔细计划在每个方向上同步哪些更改以及何时计算相应的哈希。根据您的数据,您可能需要多次同步相同的表。

同步主实体而不是关系数据? 我不知道我们是否能用同步框架做到这一点。。。也许实现一个定制的提供者?

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上的冲突。通过此示例,您可以详细说明合并策略,但情况并非总是如此。