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

Question

我正在将后端 MS Access 数据库升级到 SQL Server。前端客户端暂时还是一个Access应用(大概有3万行代码)。

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

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

GUID

专业人士:

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

缺点:

• 在 Access 中不容易操作，尤其是在将它们用作子窗体或控件的筛选器时。
• 由于其随机性而降低 INSERT 性能。
• 有不止一种表示形式:字符串、规范形式、需要转换的二进制。

自定义编码方案

我认为也许使用更统一的代码作为 PK 的方案可以避免性能损失，最重要的是，确保 PK 在必要时在表单控件中保持可用(并且不需要这些到/从字符串的转换)。

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

• 8 位数字的时间戳
• 4 位数的唯一客户 ID
• 2 位数字作为潜在碰撞的随机数每个数字将以 34 为基数，由 A-Z 和 2-9 的字母组成，避免 O、0、1、I 因为它们的相似性(以防我们需要手动处理这些 PK，例如在调试期间)。

专业人士:

• 在出现情况时更易于手动处理。
• 不需要在不同表示之间进行转换，因为它基本上是一个字符串(因此需要修改的现有代码较少)。
• 确保唯一性(实际上)

缺点:

• JOIN 中的性能尚未得到证实
• INSERT 中的性能应该比 GUID 快，但尚未证明
• 每个服务器/客户端机器都必须设置自己的 UID，尽管这应该不是什么大问题。

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

Answer 1

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

-> Access 的 GUID 为 Number->Replication Identificator。我们在 Access 中有应用程序，每个 PK 作为 GUID，我们对过滤器没有任何问题(对于 subfroms 的过滤器也是如此)。

由于其随机性而降低 INSERT 性能。

-> 如果您有基于此的性能问题，您可以在另一列(例如时间戳)上建立聚簇索引。但是 MSSQL 服务器有两个函数可以生成新的 GUID 值——“newid()”和“newsequenceid()”。第二种方法 - 顾名思义 - 按顺序生成新值，因此应该不会发生插入性能问题。

有不止一种表示:字符串、规范形式、需要转换的二进制。

-> 在我看来它是“PRO”:)。但是对于用户-开发人员和用户-管理员来说，在 Access 和 MSSQL 中以字符串形式表示和使用..

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

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