您必须决定的第一件事是关于在发生冲突更改时哪一方被视为“权威”的一般政策。
即:假设记录 #125 在 1 月 5 日晚上 10 点在服务器上更改,并且在 1 月 5 日晚上 11 点在其中一部手机(我们称之为客户端 A)上更改了相同的记录。上次同步是在 1 月 3 日。然后用户在 1 月 8 日重新连接。
确定需要更改的内容是“容易的”,因为客户端和服务器都知道上次同步的日期,因此需要协调自上次同步以来创建或更新的任何内容(有关此内容的更多信息,请参见下文)。
所以,假设唯一改变的记录是#125。您要么决定两者中的一个自动“获胜”并覆盖另一个,要么您需要支持一个协调阶段,在该阶段用户可以决定哪个版本(服务器或客户端)是正确的,并覆盖另一个。
这个决定非常重要,您必须权衡客户的“角色”。特别是如果不仅在客户端和服务器之间存在潜在冲突,而且如果不同的客户端可以更改相同的记录。
[假设 #125 可以由第二个客户端(客户端 B)修改,则尚未同步的客户端 B 可能会提供同一记录的另一个版本,从而使之前的冲突解决没有实际意义]
关于上面的“创建或更新”点......如果记录源自其中一个客户端(假设这在您的问题域中有意义),您如何正确识别记录?假设您的应用管理业务联系人列表。如果客户 A 说您必须添加一个新创建的 John Smith,而服务器有一个由客户 D 昨天创建的 John Smith……您是否创建了两条记录,因为您不能确定它们不是不同的人?你会要求用户也调和这个冲突吗?
客户是否拥有数据子集的“所有权”?即,如果客户 B 被设置为区域 #5 数据的“权威”,客户 A 是否可以修改/创建区域 #5 的记录?(这将使一些冲突解决更容易,但可能证明对您的情况不可行)。
总结起来主要问题有:
- 考虑到分离的客户端在创建新记录之前可能尚未访问服务器,如何定义“身份”。
- 以前的情况,无论解决方案多么复杂,都可能导致数据重复,因此您必须预见如何定期解决这些问题以及如何通知客户他们认为的“记录#675”实际上已被合并/取代记录#543
- 决定是否将通过法令解决冲突(例如“如果服务器版本自上次同步后已更新,则服务器版本总是胜过客户端”)或手动干预
- 在法定货币的情况下,特别是如果您决定客户端优先,您还必须注意如何处理可能会有更多变化的其他尚未同步的客户端。
- 前面的项目没有考虑数据的粒度(为了使事情更易于描述)。可以说,与其在我的示例中那样在“记录”级别进行推理,您可能会发现在现场级别记录更改更合适。或者一次处理一组记录(例如人员记录+地址记录+联系人记录),将它们的聚合视为一种“元记录”。
参考书目:
(最后三个来自 ACM 数字图书馆,不知道您是否是会员,或者是否可以通过其他渠道获得)。
从Dr.Dobbs网站:
- 使用 SQL Server CE 和 SQL RDA 创建应用程序 Bill Wagner 2004 年 5 月 19 日(为台式机和移动 PC 设计应用程序的最佳实践 - Windows/.NET)
来自 arxiv.org: