使用自定义编码方案而不是GUID作为主键

Question

我正在将后端MS Access数据库升迁到SQL Server。前端客户端暂时仍将是Access应用程序（具有大约30k行代码）。

目标是最终允许跨多个服务器同步数据库（不使用复制，但可能是同步框架） 目前，Access表中的所有主键都是自动增量整数代理。

我不是在询问升迁的过程，而是关于我是否应该使用GUID或PK的其他编码（我知道我可以分割服务器的数字范围，但我不想这样做并允许必要时在客户端上创建PK，例如在离线模式下。

GUID

临：

• 标准化格式。
• 确保唯一性（实际上无论如何）

缺点：

• 在Access中不易操作，尤其是在将它们用作子窗体或控件的过滤器时。
• 因随机性而降低INSERT性能。
• 有多个表示形式：字符串，规范形式，需要转换的二进制文件。

自定义编码方案

我认为使用更统一的代码作为PK的方案可能会避免性能损失，最重要的是，确保PK在必要时仍然可用于表单控件（并且不需要这些转换到/来自字符串）。 / p>

我对编纂方案的想法是将10个字符的代码拆分为：

• 时间戳的8位数字
• 唯一客户ID的4位数字
• 2位数作为潜在分数的随机数 每个数字都在基数34，由AZ和2-9的字母组成，避免O，0，1，I因为它们的相似性（如果我们需要手动处理这些PK，例如在调试期间。）

Pro：

当案件出现时，
• 更容易手动处理。
• 不需要在不同的表示之间进行转换，因为它基本上是一个字符串（所以现有的代码要少了很少）。
• 确保唯一性（实际上）

缺点：

• JOIN中的表现尚未得到证实
• INSERT中的性能应该比GUID快但未经过验证
• 每个服务器/客户端计算机必须设置自己的UID，但这不应该是一个问题。

那么，我应该为我的PK使用GUID还是其他方案？

Answer 1

在Access中操作起来不容易，尤其是在将它们用作子窗体或控件的过滤器时。

- ＆GT; Access具有GUID作为Number-＆gt;复制标识符。我们在Access中使用每个PK作为GUID的应用程序，我们对过滤器没有任何问题（并且还有过滤器用于subfroms）。

因其随机性而降低INSERT性能。

- ＆GT;如果您遇到基于性能问题，则可以在另一列上添加集群索引（例如，时间戳）。但是MSSQL服务器有两个用于生成新GUID值的函数 - “newid（）”和“newsequenceid（）”。第二种方法 - 如名称所示 - 按顺序生成新值，因此不应发生插入性能问题。

有多个表示形式：字符串，规范形式，需要转换的二进制文件。

- ＆GT;在我看来它的“PRO”:)。但对于用户 - 开发人员和用户 - 管理员在Access和MSSQL中表示并作为字符串使用..

GUID位于核心“唯一”128位数字中。我认为您不应该担心GUID列上的JOIN的有效性。例如，加入GUID列比文本列上的条件更有效。

我不认为自定义编纂方案是个好主意，因为你必须解决很多问题。另一方面，GUID是标准使用的，工具已准备好使用它。

Answer 2

您打算录制多少条记录？ bigint不够大吗？最多9,223,372,036,854,775,807条记录(if you don't include the negatives)

如果仅用于插入，并且没有对数据进行选择，那么请选择任何方案，（我仍然会说bigint或GUID / uniqueidentifier）。如果需要选择，则int或bigint比GUID或任何其他自定义PK快得多。