同步桌面应用程序的数据库设计

Question

我正在构建一个可在多台笔记本电脑上运行的桌面应用程序。每当用户回到办公室并再次访问时，它将需要同步到中央数据库。

我要解决的最大问题是如何设计数据库，以便与中央数据库服务器轻松同步。其中一个主要障碍是尝试确定如何处理密钥，以便它们不会在将要使用的多个笔记本电脑数据库中重复。

例如，假设笔记本电脑1进入名为“客户A”的新客户 - 使用唯一ID，可能会为其分配客户ID 20.笔记本电脑2输入“客户C” - 它也可以分配ID为20对那个客户。当需要同步时，客户A＆amp; C将以具有重复ID的服务器结束。

有没有人使用类似这个有优雅解决方案的应用程序？

Answer 1

替代方案是：

• ID范围，难以实施和执行。它们非常难以管理，难以配置新的站点/范围，甚至更难以应对退役的站点/范围。
• 复合键，（siteId，EntityId）优于范围但需要预先设计，并且可能会导致聚合多个/所有站点（中央DW）的查询出现问题，因为所有索引中最左侧的键（ siteId）未指定。
• 的的GUID 即可。从理论上讲，它们是完美的，因为它们保证了唯一性（它们可能在理论上存在冲突，我还没有看到真正的guid冲突）。实际上，由于大小（16字节）和碎片，它们是非常差的聚簇键选择。尽管如此，它们比复合键方法更容易正确。

Answer 2

使用Guids（又名uniqueidentifier）作为主键，所有复制问题都将消失。使用Guids的惩罚几乎总是被自动增加int PK的支持者夸大其词。他们需要的额外大小（16个字节对int的4个字节）是如此微不足道，以至于我对这个主题的讨论感到惊讶。 JOIN PK上Guid的查询运行速度比JOIN int PK Guid上的查询慢，但速度不是数量级（即10倍）。您的结果可能会有所不同，但我发现Guid.NewGuid() JOIN查询的执行时间延长了大约40％（在您记住摩尔定律之前，这似乎是一个很大的惩罚）。

在插入相关数据时，使用Guids for PK也可以让你摆脱困境。在插入父行之前，不必插入子记录然后检索刚刚插入的行的ID，而只需使用int创建客户端的所有ID。

我之前使用过复制系统，使用{{1}} PK分配范围来解决这个问题，但我永远不会曾再次这样做。

Answer 3

我不知道对于这个非常不优雅的问题，这是一个“优雅”的解决方案。 Remus有很好的想法，也建议你做一些关于复制的阅读。

你还可以更好地设计一个重复数据删除流程，因为在任何情况下，代表A都会在客户A中上升，而代表b也会在客户A中投放，因为它们来自不同来源，具有不同的主键，他们会有不同的记录。