当前位置:  开发笔记 > 编程语言 > 正文

GUID作为主键 - 脱机OLTP

如何解决《GUID作为主键-脱机OLTP》经验,为你挑选了1个好方法。

我们正在设计一个通常是OLTP的应用程序(想想:购买系统).但是,这个特别需要一些用户离线,因此他们需要能够将数据库下载到他们的机器上,对其进行操作,然后在局域网上进行同步.

我想要注意的是,我知道之前已经完成过,我只是没有这个特定模型的经验.

我想到的一个想法是使用GUID作为表键.因此,例如,采购订单不会有数字(自动数字)而是GUID,因此每个离线客户端都可以生成这些数据,并且当我连接回数据库时我没有冲突.

出于某种原因,这是一个坏主意吗?通过GUID键访问这些表会很慢吗?

您是否有过使用这类系统的经验?你是怎么解决这个问题的?

谢谢!
丹尼尔



1> Simon Munro..:

使用Guids作为主键是可以接受的,并且由于您考虑它们的相同原因而被认为是相当标准的练习.它们可能被过度使用,这会使调试和管理变得有些繁琐,因此尽可能地将它们从代码表和其他参考数据中保留下来.

您必须关注的是人类可读的标识符.Guids不能被人们交换 - 你能想象如果它是一个guid,试图通过电话确认你的订单号吗?因此,在离线方案中,您可能仍需要生成某些内容 - 例如发布者(工作站/用户)ID和某个序列号,因此订单号可能是123-5678 - .

但是,这可能无法满足具有序号的业务要求.事实上,监管要求可能会受到影响 - 某些法规(SOX可能)要求发票号码是连续的.在这种情况下,可能需要生成一种形式编号,该编号稍后在系统同步时修复.您可能会使用具有OrderId(Guid),OrderNo(int),ProformaOrderNo(varchar)的表 - 可能会出现一些复杂性.

至少将guids作为主键意味着当最终发生同步时,您不必执行大量级联更新 - 只需更新人类可读的数字即可.

推荐阅读
手机用户2402852387
这个屌丝很懒,什么也没留下!
DevBox开发工具箱 | 专业的在线开发工具网站    京公网安备 11010802040832号  |  京ICP备19059560号-6
Copyright © 1998 - 2020 DevBox.CN. All Rights Reserved devBox.cn 开发工具箱 版权所有