sql-server - GUID 作为主键 - 离线 OLTP

Question

我们正在致力于设计一个典型的 OLTP 应用程序(例如:采购系统)。然而，这个特别需要一些用户处于离线状态，因此他们需要能够将数据库下载到他们的计算机上，对其进行处理，然后在连接到 LAN 后同步回来。

我想指出的是，我知道以前已经这样做过，我只是没有使用此特定模型的经验。

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

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

您有使用此类系统的经验吗？您是如何解决这个问题的？

谢谢!
丹尼尔

Answer 1

使用 Guid 作为主键是可以接受的，并且被认为是相当标准的做法，原因与您正在考虑使用它们的原因相同。它们可能会被过度使用，这会使调试和管理变得有点乏味，因此如果可能的话，请尽量将它们排除在代码表和其他引用数据之外。

您必须关心的是人类可读的标识符。人们无法交换指南 - 如果是指南，您能想象尝试通过电话确认您的订单号吗？因此，在离线场景中，您可能仍然需要生成某些内容 - 例如发布者(工作站/用户)ID 和一些序列号，因此订单号可能是 123-5678 -。

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

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