同步到主数据库时，人们如何处理客户端上的外键答案

【问题标题】：How do people handle foreign keys on clients when synchronizing to master db同步到主数据库时，人们如何处理客户端上的外键
【发布时间】：2010-03-26 23:44:41
【问题描述】：

我正在编写一个具有离线支持的应用程序。即浏览器/移动客户端每隔一段时间将命令同步到主数据库。

我在客户端和服务器端都使用 uuid。同步到服务器时，服务器将返回本地 uuid (luid) 到服务器 uuid (suid) 的映射。收到此地图后，客户端会使用适当的值更新其记录 suid 属性。

但是，比如说客户记录，例如待办事项有一个属性“list_id”，它保存待办事项列表记录的外键。我在客户端的 foreign_keys 中使用 luids。但是，当将该属性发送到服务器时，它会使用 luids 而不是服务器正在使用的 suid 弄脏服务器数据库。

我当前的解决方案是让主服务器记录 luid 到 suid（每个客户端 id）的映射，并且对于命令中的每个外键，查找该特定客户端的 suid 并改用 suid .

我想知道其他人是否遇到过这样的问题，如果遇到过，他们是如何解决的？有没有更高效、更简单的方法？

我查看了这个问题“将一个或多个数据库与主数据库同步 - 外键 (5)”，有人似乎建议我当前的解决方案作为一个选项，使用 suid 和自动递增序列的复合键和另一个选项使用-ve ids 用于客户端 ID，然后使用 suid 更新所有否定 ID。这两个其他选项似乎都需要更多的工作。

谢谢，

赛蒙

【问题讨论】：

标签： database synchronization

【解决方案1】：

根据我的经验，采用组合方法是最简单的方法，尤其是在调试问题和潜在的回滚需求时，即了解哪些请求来自哪台机器并导致了哪些更改非常有帮助。每当您有效地处理多对一时，您必须有一种方法来有效地隔离所有这些，当您有两个非互补的“多”发送更新时，它还允许您进行更智能的冲突管理（如果你想做那种事情）。

【讨论】：

谢谢 driss，我想将客户端 ID 前缀到 luid 并不是一个坏主意，正如您所说，出于回滚/调试目的可能值得。

【解决方案2】：

我刚刚想到了另一种可能性：

在客户端分配 luid 时，保留该 luid 的所有分配的地图，例如

类似（json）的东西：

  {
   'luid123': [{model: list, attribute: 'id'}, 
             {model: todo, attribute: 'list_id'}]
  }

当我们从服务器获取全局 luid2suid 映射时（同步后），对于每个 luid，我们在 luid 映射中查找 luid，并为每个条目相应地使用 guid 更新相应模型中的相应属性，然后删除来自 luid 映射的条目。

你怎么看？

这样我就避免了在全局 luid2suid 映射中对所有同步命令的外键进行昂贵的查找。另一个好处是外键也是客户端上的所有 suid，我只需要从服务器端的 luid 中查找 suid，以了解离线记录创建和修改的情况，然后再同步回服务器。

这只是我脑海中突然出现的一个想法。我仍然希望有关该主题的更多反馈

【讨论】：