使用自定义编码方案代替GUID作为主键

Question

我正在将后端MS数据库升级到Server。前端客户端暂时仍然是一个访问应用程序(大约有30k行代码)。

其目的是最终允许数据库跨多个服务器进行同步(不使用复制，但可能使用同步框架)。

当前，Access表中的所有主键都是自动增量整数代理。

我不是在问升级的过程，而是问我是否应该为PK使用GUID或另一个编码(我知道我可以在服务器上拆分数量范围，但我不想这样做，如果需要的话允许在客户机上创建PK，例如在脱机模式下)。

GUID

专业：

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

缺点：

• 在访问中不容易操作，特别是当将它们用作子窗体或控件的筛选器时。
• 由于插入的随机性降低了插入性能。
• 有多个表示形式:字符串、规范形式、需要转换的二进制。

自定义编码方案

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

我对编码方案的想法是按照10个字符代码分成：

• 一个时间戳的8位数字
• 唯一客户端ID的4位数字
• 两个数字作为潜在合并的随机数，每个数字的基数为34，由as和2-9的字母组成，避免使用O、0、1、I，因为它们具有相似性(如果我们需要手动处理这些PK，例如在调试期间)。

专业：

• 在出现这种情况时，手动操作更容易。
• 不需要在不同的表示之间进行转换，因为它基本上是一个字符串(因此没有那么多现有代码来适应)。
• 确保独特性(实际上)

缺点：

• 在JOIN中的性能还没有被证明
• INSERT中的性能应该比GUID更快，但没有得到验证。
• 每台服务器/客户端机器都必须设置自己的UID，尽管这不应该是太大的问题。

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

Answer 1

在访问中不容易操作，特别是当将它们用作子窗体或控件的筛选器时。

->访问以GUID作为编号->复制标识符.我们在每个PK作为GUID的访问应用程序，我们没有任何问题的过滤器(以及过滤器的子程序也)。

由于其随机性降低了插入性能。

->如果您有基于此的性能问题，则可以在另一列(例如时间戳)上设置集群索引。但是MSSQL服务器有两个函数来生成新的GUID值-- "newid()“和"newsequenceid()”。第二个方法--顾名思义--按顺序生成新值，因此不应该发生insert performace问题。

有多个表示形式:字符串、规范形式、需要转换的二进制。

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

GUID位于核心“仅”128位数字中。我认为您不应该担心GUID列上联接的有效性。例如，联接GUID列比对文本列的条件要有效得多。

我不认为习惯编码方案是个好主意，因为你必须解决许多问题。另一方面，GUID是标准使用的，工具已经准备好使用它了。

Answer 2

你打算录多少张唱片？比金不够大吗？最高达9,223,372,036,854,775,807记录(如果你不包括底片)

如果它仅用于插入，而没有对数据进行选择，则选择任何方案(我仍然会说bigint或GUID/unique标识符)。如果需要进行选择，int或bigint要比GUID或任何其他自定义PK快得多。