作为主键的GUIDs脱机OLTP
我们正在设计一个典型的OLTP应用程序(想想:采购系统)。但是，这个特别需要一些用户离线，因此他们需要能够将DB下载到他们的机器上，对其进行操作，然后在连接到LAN后再同步回来。
我想指出的是，我知道以前也这样做过，我只是没有使用这种特殊模型的经验。
我考虑过的一个想法是使用GUID作为表键。因此，例如，购买订单不会有一个数字(自动数字)，而是一个GUID，这样每个离线客户端都可以生成GUID，并且当我连接回数据库时不会有冲突。
出于某种原因，这是个坏主意吗？通过GUID键访问这些表会很慢吗？
您有使用这些类型的系统的经验吗？你是如何解决这个问题的？
谢谢!
丹尼尔
回答 15
Stack Overflow用户
发布于 2008-09-02 18:56:50
使用Guids作为主键是可以接受的，并且被认为是一种相当标准的实践，原因与您正在考虑它们的原因相同。它们可能会被过度使用，这会使调试和管理变得有点单调乏味，所以如果可能的话，尽量将它们排除在代码表和其他参考数据之外。
您必须关注的是人类可读的标识符。guid不能被人交换-如果是guid，你能想象尝试通过电话确认你的订单号吗？因此，在离线情况下，您可能仍然需要生成一些 -例如发布者(工作站/用户) id和一些序列号，因此订单号可能是123-5678 -。
但是，这可能无法满足具有序列号的业务需求。事实上，监管要求是可以影响的-一些法规(可能是SOX)要求发票编号是连续的。在这种情况下，可能有必要生成一种形式编号，该编号稍后在系统同步时进行修复。你可能会得到包含OrderId (Guid)、OrderNo (int)、ProformaOrderNo (varchar)的表--一些复杂性可能会潜入其中。
至少将guids作为主键意味着当同步最终发生时，您不必进行大量的级联更新-您只需更新人类可读的数字即可。
Stack Overflow用户
发布于 2008-09-03 02:14:24
@SqlMenace
GUID还有其他问题，您可以看到GUID不是连续的，因此插入将分散在各处，这会导致页面拆分和索引碎片
不是这样的。主键!=聚集索引。
如果聚集索引是另一列(脑海中浮现出“inserted_on”)，那么插入将是顺序的，不会发生页面拆分或过度的碎片。
Stack Overflow用户
发布于 2008-09-02 18:41:55
这是GUID的完美用法。唯一的缺点是在INTs上使用GUID时会有轻微的复杂性，以及细微的大小差异(16字节与4字节)。
我认为这两个都不是什么大问题。
https://stackoverflow.com/questions/40230
复制相似问题
腾讯云开发者
