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

发布于 2024-08-26 22:50:25 字数 623 浏览 6 评论 0原文

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

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

然而,假设客户记录(例如待办事项)具有属性“list_id”,该属性保存待办事项列表记录的外键。我在客户端的foreign_keys中使用luids。但是,当该属性发送到服务器时,它会使用 luids 而不是服务器正在使用的 suid 来弄脏服务器数据库。

我当前的解决方案是让主服务器保留 luids 到 suids 的映射记录(每个客户端 id),并且对于命令中的每个外键,查找该特定客户端的 suid 并使用 suid 代替。

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

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

谢谢,

赛蒙

I'm writing an application with offline support. i.e. browser/mobile clients sync commands to the master db every so often.

I'm using uuid's on both client and server-side. When synching up to the server, the servre will return a map of local uuids (luid) to server uuids (suid). Upon receiving this map, clients updated their records suid attributes with the appropriate values.

However, say a client record, e.g. a todo, has an attribute 'list_id' which holds the foreign key to the todos' list record. I use luids in foreign_keys on clients. However, when that attribute is sent over to the server, it would dirty the server db with luids rather than the suid the server is using.

My current solution, is for the master server to keep a record of the mappings of luids to suids (per client id) and for each foreign key in a command, look up the suid for that particular client and use the suid instead.

I'm wondering wether others have come across thus problem and if so how they have solved it? Is there a more efficient, simpler way?

I took a look at this question "Synchronizing one or more databases with a master database - Foreign keys (5)" and someone seemed to suggest my current solution as one option, composite keys using suids and autoincrementing sequences and another option using -ve ids for client ids and then updating all negative ids with the suids. Both of these other options seem like a lot more work.

Thanks,

Saimon

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(2

风吹短裙飘 2024-09-02 22:50:25

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

From my experience it's easiest taking the composition approach, particularly when it comes to debugging issues and potential needs for rolling back, i.e. it's really helpful to know what requests came from what machine and resulted in what changes. Whenever you're effectively dealing with many to one you have to have a way to effectively isolate all of the many, it also allows you to do more intelligent conflict management when you have two of the 'many' sending updates that are non-complementary (if you want to do that sort of thing).

¢蛋碎的人ぎ生 2024-09-02 22:50:25

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

在客户端分配 luids 时,保留该 luid 的所有分配的映射,例如

(json):

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

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

你怎么认为?

这样我就可以避免在全局 luid2suid 映射中为同步命令的所有外键进行昂贵的查找。另一个好处是,外键在客户端上也都是 suids,在同步回服务器之前,我只需要从服务器端的 luids 中查找 suids 来进行离线记录创建和修改。

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

I've just thought of another possibility:

When assigning luids on the client-side, keep a map of all assignments of that luid e.g.

something like (json):

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

When we get the global luid2suid map from the server (after sync up), for each luid we look up the luid in the luid map and for each entry update the appropriate attribute in the appropriate model with the guid accordingly and then remove the entry from the luid mapping.

What do you think?

This way I avoid having to do expensive look ups in the global luid2suid map for all foreign keys of command synched. Another benefit is that foreign keys are all suids on the client too and I'd only have to look up suids from luids on the server side for cases of offline record creation and modification before synching back to server.

It's just an idea that just popped into my head. I'm still hoping for more feedback on the subject

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文