我知道 GUID 几乎是独一无二的。但是，假设它是独一无二的，这种做法是否可以接受？

Question

所以我完全理解创建两个具有相同数字的GUID值的数学可能性。但是，假设它们是独一无二的，这种做法是否可以接受？

例如，我正在使用一个处理医疗文件的系统。当我开始布局数据库结构时，经理（技术知识不是很丰富，但喜欢认为他是并且委托的事情最好留给更有技术头脑的人来决定）说他想使用 GUID 来分隔不同的医疗记录INT 因为它“更独特”。我解释了 INT 如何总是独一无二的，因为它是连续的。我建议我们使用 BigINT，如果它能让他感觉更舒服，因为有更多的数字，那么如果地球上的人口增加到人们只能在地球上彼此并排站立的地步，但他坚持使用GUID。

我的感觉是，虽然几乎不可能发生混淆，但在处理病历时，为什么要冒险呢？在这种情况下使用 GUID 与 INT 的优势是什么？

Answer 1

但是，假设它是独一无二的，这种做法是否可以接受？

是的。这就是UUID的全部目的，在没有集中协调的情况下用作可靠的唯一标​​识符。（GUID是 Microsoft 对 UUID 的变体。）

只有您（或您的适当管理层）才能对您的特定项目做出最终判断。

但是，如果您真的开始意识到 12x 位数值范围的巨大（这对于人类的大脑来说实际上是不可理解的），那么您就知道可以从您的担忧列表中删除正确生成的 UUID 的使用。

通过“正确生成”，我的意思是使用日期时间版本，或者如果由加密强随机数生成器支持，则使用随机数（版本 4）。今天几乎每个现代操作系统都包含一个 UUID 生成库。或者您可以使用OSSP UUID项目。不正确的生成将包括您可能会在互联网上看到的滚动您自己的实现。

至于使用数据库的自动递增序列号/序列号的建议，我认识的每个拥有多年实际经验的数据库人员都被那些烧毁了。我从未听说或读过任何人与正确生成的 UUID 发生冲突的情况。我并不是说序列一定是坏的或没有它们的位置，我只是说当我听到人们因为 UUID 的一些超天文无法理解的微小可能性而远离 UUID 时，我所能做的就是大笑碰撞并选择一个序列。

在处理病历时，为什么要冒险？

由于错误的数据输入或处理记录的其他人为错误，您的医疗系统更有可能出现故障。但是，您是否会派 3 名值班职员独立三次输入相同的数据以减少出错的机会？不。而且这种风险在数学上比 UUID 问题更容易发生。然而，我所知道的每一个医疗机构都没有考虑过这种巨大的风险。

使用 GUID 与 INT 的优势是什么

优点包括：

• 无需管理您的序列。
  示例包括： 针对开发、测试和生产环境进行重置。或者在恢复备份时。或者在系统的串行生成库中出现故障后修复序列（我自己的经验）。
• 避免用户的直觉假设混淆序列中缺失的数字。
  我经常有这样的谈话。
• 在分布式系统之间联合数据。
  这是最大的优势，每个系统都可以独立运行，但可以轻松地与其他系统来回共享数据。如果没有 UUID，管理开销和错误风险一开始会很麻烦，而且只会随着时间的推移而增加。

缺点包括：

• 更大的内存和存储使用量。
  序列号通常是 32 位整数，有时是 64 位。原生支持 UUID 作为数据类型的良好数据库将使用 128 位。
• 人类可读性较差。
  一种解决方法是仅读取几个第一个或最后一个数字以用于临时工作。
• 索引效率可能较低，条目数量非常多。