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

Question

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

我最大的问题要克服的是如何设计的数据库，因此，它很容易与中心数据库服务器同步。其中一个主要障碍是试图确定如何处理密钥，以防止它们在将要使用的多台笔记本电脑数据库中重复使用。

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

有没有人有与此类似的有一个优雅的解决方案的应用程序的工作？

Answer 1

替代有：

• 范围IDS的，这是难以实现和执行。他们很难管理，很难提供一个新的网站/范围，更难以应对退休的网站/范围。
• 组合键，（网站ID，ENTITYID）比范围更好，但需要前期设计，因为没有指定在所有指标中最左边的键（网站ID）是可能会导致对聚集多个/所有站点（DWS中心）查询问题。
• 的GUID。从理论上讲，它们是完美的，因为它们保证了独特性（它们可能在理论上有冲突，我还没有看到真正的指导冲突）。实际上，由于大小（16字节）和碎片，它们是非常差的群集密钥选择。尽管如此，它们比组合键方法更容易得到。

Answer 2

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

你也更好地设计了一个重复删除过程，因为无论什么情况下，代理A会在客户A中上升，代表b也将投入到客户A中，并且因为它们来自不同的来源，键，它们将是不同的记录。

Answer 3

使用的GUID（又名uniqueidentifier）为您的主键，和你所有的问题，复制将消失。使用Guids的惩罚几乎总是被自动增量int PKs的支持者夸大其词。他们所需要的额外大小（16字节，而对于int，则为4字节）是如此微不足道，以至于我对它在讨论这个问题时感到惊讶。的查询JOIN上Guid的PK将比的查询JOIN上int的PK运行速度较慢，但​​它不是一个订单的数量级（即10X）速度较慢。你的结果可能会有所不同，但我发现Guid JOIN查询的执行时间延长了40％左右（这可能看起来像是一个很大的惩罚，直到你记得摩尔定律）。

使用的的PK的GUID也让你出去干什么真正哈克的东西，当你插入相关数据。不必插入子记录，然后在插入父行之前检索刚刚插入的行的ID，只需使用Guid.NewGuid()创建客户端的所有ID即可。

我和复制系统工作之前，int的PK是用来分配范围来解决这个问题，但我绝不会永远再次做到这一点。