问我知道吉德几乎是独一无二的。但是，假设它是独一无二的做法是否可以接受呢？

EN

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

是的。是UUID的全部用途，可以作为一个可靠的唯一标识符使用，而不需要集中协调。( 参考线是微软UUID的变体。)

只有您(或您的适当管理人员)才能对您的特定项目做出最终判断。

但是，如果你真的开始意识到12x位的数值范围的巨大性(这实际上是人类头脑所无法理解的)，那么你就知道你可以从你的忧虑列表中删除正确生成的UUID的用法。

所谓“正确生成”，我指的是使用日期-时间版本，或者对于较低数量的值，如果有加密强随机数生成器支持，则使用随机(版本4)。当今几乎每一个现代操作系统都包括一个UUID生成库。或者您可以使用OSSP UUID项目。不恰当的生成将包括您自己的滚动实现，您可能会看到关于跨网的班格。

至于使用数据库自动递增的序列号/序列号的建议，我所认识的每一个具有多年真实世界经验的数据库人都被这些人烧掉了。我从未听说过或阅读过任何与正确生成的UUID发生冲突的人。我并不是说序列一定是坏的，或者没有它们的位置，我只是想说，当我听到人们因为一些无法理解的、难以理解的UUID碰撞的可能性而离开UUID，而选择一个序列时，我所能做的就是笑。

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

由于错误的数据输入或处理记录的其他人为错误，您的医疗系统更有可能失败。但你是否派了3名值勤的职员独立地三次输入相同的数据，以减少出错的可能性？不是的。与UUID问题相比，这种风险在数学上更有可能发生。然而，我所知道的每一个医疗机构都接受这种巨大的风险，甚至连想都不去想。

使用GUID和INT的优点是什么？

这些优点包括：

• 不需要管理你的序列。 示例包括:为开发、测试和生产环境重置。或者在恢复备份的时候。或者修复系统串行生成库中故障后的序列(我自己的经验)。
• 避免用户的直觉假设对序列中缺少的数字感到困惑。 我谈得太频繁了。
• 分布式系统之间的联邦数据。 这是最大的优势，每个系统可以独立工作，但可以轻松地与其他系统之间共享数据。如果没有UUID，管理开销和出错风险一开始就很麻烦，而且只会随着时间的推移而增加。

缺点包括：

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

使用递增的整数ID只确保它自己的域/类型内的唯一性，UUID/GUID的一个优点是它们唯一地标识整个宇宙中拥有的东西。

因此，如果您有多个对象，比如MedicalRecord, ID = 5，VaccinationForm, ID = 5，那么您需要指定两种类型("medicalRecord“或"vaccinationForm”，ID值为5)，而对于GUID，您只需要存储单个量子信息来唯一标识它。

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

如果您的系统是独立的，并且不与其他表进行接口，那么您可能需要使用Server的“序列”概念，在这个概念中，不是每个表存储自己的标识序列，而是维护所有表的序列，使其成为一个本地唯一的ID值。您也可以使用任意大小的整数。

见此处：https://msdn.microsoft.com/en-us/library/ff878091.aspx