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

Question

所以我完全理解用相同的数字创建两个GUID值的数学不可靠性。但是，假设它们是独一无二的，这是否可以接受呢？

例如，我正在使用一个处理医疗文件的系统。当我开始布局数据库结构时，管理员（技术上不是很了解，但他喜欢认为他是并且委托最好留下更专业的人决定的东西）说他想用GUID来分隔不同的医疗记录而不是因为它是“更独特”的INT。我解释了INT如何始终是唯一的，因为它是顺序的。我建议我们使用BigINT，如果它会让他感觉更舒服，因为当时有更多的数字，如果地球的人口增加到人们只能在地球上彼此相邻的点，但他坚持使用的GUID。

我的感觉是，虽然在处理医疗记录方面几乎是不可能的，但为什么要抓住机会呢？在这种情况下使用GUID与INT有什么好处？

Answer 1

使用递增的整数ID确保其自身的域/类型中只有唯一性，UUID / GUID的一个优点是它们可以唯一地标识整个Universe中拥有的 thing 。

因此，如果你有多个对象，比如说MedicalRecord, ID = 5，VaccinationForm, ID = 5那么你需要同时指定类型（“medicalRecord”或“vaccinationForm”，ID值为5）而使用GUID，您只需存储一个量子信息即可唯一识别它。

可以说使用GUID是浪费空间，因为它们长度为16个字节（128位值）。

如果您的系统是独立的并且没有与其他系统连接，您可能希望使用SQL Server的“序列”概念，而不是每个表存储其自己的标识序列，为所有表维护序列，使其成为本地 - 独特的ID值。您也可以使用任何大小的整数。

见这里：https://msdn.microsoft.com/en-us/library/ff878091.aspx

Answer 2

  

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

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

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

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

通过“正确生成”我的意思是使用日期时间版本，或者对于较低数量的值使用随机（版本4），如果由加密强随机数生成器支持。现在几乎每个现代操作系统都包含一个UUID生成库。或者您可以使用OSSP UUID项目。 不正确的生成将包括你自己的实施，你可能会看到有关网络间的信息。

至于使用数据库的自动递增序列号/序列号的建议，我认识的具有多年实际经验的每个数据库人员都被这些人烧掉了。我从来没有听说过任何与正确生成的UUID发生冲突的人。我并不是说序列一定是坏的或者没有他们的位置，我只是说当我听到人们因为一些超天文学的转变而离开UUID时我所能做的就是笑难以理解的UUID碰撞的可能性很小，而是选择一个序列。

  在处理医疗记录时，为什么要抓住机会呢？

由于数据输入错误或处理记录中的其他人为错误，您的医疗系统更有可能失败。但是你是否会派出3名值班人员独立三次输入相同的数据以减少出错的几率？没有。与UUID问题相比，这种风险在数学上难以理解。然而，我所知道的每一家医疗机构都承认这种巨大的风险，甚至没有考虑过它。

  

使用GUID与INT

的优点是什么？

优势包括：

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

缺点包括：

• 更大的内存和存储空间使用。
  序列号通常是32位整数，有时是64位。具有UUID原生支持作为数据类型的good database将使用128位。
• 人类不太可读。
  一种解决方法是只读几个偶数作品中的几个或最后一个数字。
• 索引效率可能较低，条目数量非常多。