更好的自动编号主键替代方案

Question

我正在寻找比自动编号数据类型更好的主键，原因是它仅限于长整数，而我实际上只需要反映一个数字或文本字符串的字段，无论添加或删除多少记录，都不会重复。问题是我不确定如何实现将当前日期和时间转换为十六进制字符串，并将其用作我可以用作主键的唯一字段。

我是不是太担心空间不足了？

-编辑03-16-2010 @ 1237小时-

曾经有一位我认为对Access相关问题非常了解的人告诉我，复制ID只是一个项目被复制的次数计数器...因此我没有进一步探索。在得到许多回复后，我已经采纳了一个答案。我想我只是一个愚蠢的新手Access开发者。但真的，再次感谢所有回复我的人！

- Comrad_Durandal

---

自动编号字段是一个长达4字节的字段，最多可以有2,147,483,647条记录。此外还有负数，另外可以再存储-2,147,483,648条记录。如果您担心空间不足，我建议您将数据存储在除Access aka Jet格式之外的其他数据系统中。 - Tony Toews

不清楚您是否在Access中编写应用程序。如果是这样，那么正如Tony Toews在下面的评论中引用的Michael Kaplan文章所述，您刚刚为开发过程添加了问题。您可能对此感到满意，但我认为，认为他们需要在没有外部依赖强制要求的情况下在Access应用程序中使用GUID的人大多是在愚弄自己并引入不必要的开发问题。但请注意，我说的是“大多数”，而不是“总是”。 - David-W-Fenton

Answer 1

GUID。它们非常独特

http://en.wikipedia.org/wiki/Globally_Unique_Identifier

你没有提到你使用的编程语言。 C# 的话可能是这样的：

String myKey = Guid.NewGuid().toString();

- Kieran

---

在考虑GUID之前，请阅读以下文章。主题：INFO：复制和GUID，好的，坏的和丑陋的 http://www.trigeminal.com/usenet/usenet011.asp?1033 - Tony Toews

如果您将数据库设置为具有文本值，并手动放置GUID，是否可以解决链接中列出的所有问题？至于第4点，“没有人愿意成为数字，就像他们不想成为随机一堆字母一样”。如果我在制作系统，它应该能够在没有使用主键的情况下找到记录。 - Kieran

转换为文本类型将改变索引，这可能不太高效（GUID中的字母不是文本，而是十六进制数字）。但我不确定——我从未见过使用GUID作为PK的原因（尽管我所有复制的数据库都使用它们进行复制功能，这是我完全交给数据库引擎处理的）。 - David-W-Fenton

Answer 2

你为什么认为你会用完空间？也许你没有意识到一个64位整数有多大。它可以容纳约10万亿个记录。如果你每秒创建100个记录，那么用完整数需要超过五十亿年的时间。

- John Kugelman

---

Access的“Long”类型只有32位。 - Gabe

哇！！！只有32位！如果Jet/ACE作为应用程序的数据存储是合适的，那么Jet/ACE的长整型就足够了。如果第一个条件不满足，则问题不在于选择自动编号作为主键。 - David-W-Fenton

从技术上讲，Microsoft Access仅使用4个字节来存储长整型数据，因此出现了最初的问题 - 但我已经得到了一个可行的答案。谢谢。 - Comrad_Durandal

Answer 3

为什么你只能使用长整型？当你指定一个自动编号字段时，你可以告诉它使用一个名为GUID的唯一128位值，而不是长整型。

虽然你可以使用当前日期和时间作为主键，但以下是不建议这样做的原因：

当前日期和时间并不像你想象的那么独特。如果你非常快地创建记录，可能会在时钟滴答之间插入两个记录，导致两个记录具有相同的时间。或者你的计算机时钟可能会被重置回去。或者夏令时结束了，如果你存储本地时间，你将得到重复的时间。

- Gabe

---

我不建议将DateTime时间戳作为主键。 - Kieran

事实上，Kieran，我的帖子大部分内容都是解释为什么这不是一个好主意。 - Gabe

编辑后加1。复制ID是特定于数据库的，无需将其放入代码中。比我的解决方案更好。 - Kieran

Answer 4

根据约翰的回答，您不太可能用尽长整数。但如果您想要一个唯一的字符串，最简单的解决方案是 UUID。它不需要输入，但生成两个相同的 UUID 的概率几乎为零。

例如，在 Python 中：

import uuid
uuid.uuid4()

大多数编程语言都提供了UUID函数：http://en.wikipedia.org/wiki/Uuid

- Tom

---

在何种情况下，Jet/ACE是一个适当的数据存储方式，你会用完长整型？ - David-W-Fenton

Answer 5

一个非常简单的解决方案是使用带有“随机”选项而不是“递增”的自动编号。我在某个地方读到过，由于数字不是连续的，因此在同时从多个客户端添加新记录时，它具有提高并发性的额外优势。

- iDevlop

---

实际上，在添加记录时，并不会提高并发性，因为新记录（以及相应的索引值）将存储在新的数据页中。但是对于在紧凑文件中编辑现有数据，则理论上可以将数据均匀分布在所有数据页上，这可能会提高并发性。但只有在压缩后才能获得完美的结果，并且仅适用于编辑现有记录，而不是记录添加。 - David-W-Fenton

@David，谢谢你的解释。现在我想起来了，我记得在你在SO上的一篇帖子中看到过这个信息。有趣...并且记住了;-) - iDevlop