所以我完全理解用相同的数字创建两个GUID值在数学上的不可能性。但是，假设它们是唯一的做法可以接受吗?
例如，我正在使用一个处理医疗文件的系统。当我开始布局数据库结构时，经理(不太懂技术，但喜欢认为他是，并委托的事情最好留给更有技术头脑的人来决定)说他想使用GUID来分离不同的医疗记录，而不是INT，因为它"更独特"。我解释过INT总是唯一的因为它是顺序的。我建议我们使用BigINT，如果它会让他感觉更舒服，因为有更多的数字，然后如果地球上的人口增加到一个点，人们只适合站在一个星球上，但他坚持使用guid。
我的感觉是，虽然在处理医疗记录时几乎不可能出现混淆，但为什么要冒这个险呢?在这种情况下使用GUID和INT的优势是什么?
但是假设它是唯一的做法可以接受吗?
是的。这就是UUID的全部目的，作为一个可靠的唯一标识符，不需要集中协调。(GUID是微软对UUID的变体。)
只有您(或您的适当管理人员)才能对您的特定项目做出最终判断。
但是，如果您真正开始理解12x位数字范围的巨大(这实际上是人类无法理解的)，那么您就知道可以将正确生成的UUID的使用从您的担忧列表中删除。
通过"正确生成"，我的意思是使用日期时间版本，或者对于较低数量的值使用随机(版本4)，如果由加密强随机数生成器支持。如今，几乎每个现代操作系统都包含一个UUID生成库。或者您可以使用OSSP UUID项目。不正确的生成将包括您可能在互联网上看到的自己的实现。
至于使用数据库的自动递增的序列号的建议，我认识的每一个有多年实际经验的数据库人员都被这些建议烫伤了。我从来没有听说过或读到过有人与正确生成的uid发生冲突。我并不是说序列一定是坏的或者没有它们的位置，我只是说，当我听到人们因为UUID碰撞的一些超出天文上不可理解的微小可能性而放弃UUID并选择序列时，我所能做的就是笑。
在处理医疗记录时，为什么要冒险?
你的医疗系统更有可能因为错误的数据输入或其他处理记录的人为错误而失败。但是你会让三个值班的职员独立地三次输入相同的数据来减少出错的可能性吗?不。从数学上讲，这种风险比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位值)。
如果你的系统是自包含的，并且不与其他系统接口，你可能想要使用SQL Server的"序列"概念，其中不是每个表存储自己的标识序列，而是为所有表维护序列，使其成为本地唯一的ID值。你也可以使用任意大小的整数
请看这里:https://msdn.microsoft.com/en-us/library/ff878091.aspx