长vs Guid Id(实体)，有哪些优点和缺点

Question

我在做一个网上应用程序asp.net 视和我之间进行选择的漫长和Guid数据类型我的实体，但是我不知道哪一个是更好。有人说，长速度要快得多。Guid也可能有一些优点。有人知道？

Answer 1

：当的GUID可以是不适当

的GUID几乎总是会因为它们较大的要慢一些。这使得你的索引更大。这使得你的表大。这意味着，如果你要扫描您的表，无论是全部或部分，这将需要更长的时间，你会看到更少的性能。这是基于报告系统一个巨大的关注。例如，一个永远不会使用GUID作为事实表的外键，因为它的长度通常会是显著，因为事实表通常局部扫描，以产生聚集。

也可以考虑它是否是适当的使用“长”。这是一个极其庞大的数字。你只需要它，如果你认为你可能在你的表中超过20亿的条目在某些时候。这是罕见的，我使用它们。

的GUID也可能会很难使用和调试。他说：“有一个与客户记录的问题10034，弗兰克，去看看”是不是说要容易得多“有一个与{2f1e4fc0-81fd-11DA-9156-00036a0f876a}个问题......” INTS和多头也更容易当你需要输入到查询。

哦，这不是永远，你的的情况下的得到相同的GUID两次。已经知道在非常大的，割裂的系统发生的，所以这是要考虑的事情，虽然我不会在大多数应用程序的设计吧。

：当的GUID，可以适当

的GUID的是的，当你与在实体创建，然后同步断开系统工作合适。例如，如果有人做记录在数据库中在移动设备上同步和它，或者你有不同的分支机构正在创建晚上同步到中央存储实体。这就是这种灵活性，他们给你。

的GUID也让你的实体没有他们坚持到数据库中，在某些情况下ORM相关联的能力。 LINQ到SQL（我相信EF）没有这个问题，但也有可能会被迫更改提交给数据库来获取一个关键时刻。

如果您在客户端上创建的GUID，它可能是因为你创建的GUID是不连续的，即插入性能可能因为数据库页拆分之苦。

我建议

这是很多的东西在这里考虑的问题。我的投票，除非你对他们有一个令人信服的用例不使用他们。如果性能真的是你的目标，保持你的表很小。保持你的领域很小。保持你的数据库索引小和选择性。

Answer 2

尺寸： 长为8个字节 Guid16字节

GUID有 肯定 高的概率，对于要独特的 和最好是用于识别的个人记录在一个数据基(s)。

长(身份在DB),可能表示一个独特的记录在一个表，但你可能已经记录表示同样的身份证件(身份)，一种或多种不同的表如下：

TableA: PersonID int, name varchar(50)
TableB: ProductID int, name varchar(50)

SELECT PersonID from TableA where name =''
SELECT ProductID from TableB where name =''

两者可以返回相同的价值，但在情况下的GUID：

TableA: PersonID uniqueidentifier, name varchar(50)
TableB: ProductID uniqueidentifier, name varchar(50)

SELECT PersonID from TableA where name =''
SELECT ProductID from TableB where name ='

你可以很少有相同的价值为id返回的两个表中的

看看这里

• SQL服务器-Guid VS。长
• Guid作为主键和/或集群关键

Answer 3

的GUID使其更容易创建您的API在“新鲜”的实体，因为你只需要给它Guid.NewGuid的值（）。有一个关于从数据库自动递增键不依赖，所以这更好从底层的持久性机制解耦域模型。

在不利的一面，如果你使用GUID作为聚集索引在SQL Server中，刀片变得昂贵，因为新行很少添加到表的末尾，所以索引必须经常重建。

另一个问题是，如果你没有指定明确排序执行从这样的数据库选择，你在一个基本上是随机的顺序走出的结果。