15

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

4

3 回答 3

20

当 GUID 可能不合适时

GUID 几乎总是会变慢，因为它们更大。这会使您的索引更大。这使您的桌子更大。这意味着如果您必须全部或部分扫描您的表，这将花费更长的时间，并且您会看到更少的性能。这在基于报告的系统中是一个巨大的问题。例如，永远不会使用 GUID 作为事实表中的外键，因为它的长度通常很重要，因为事实表通常会被部分扫描以生成聚合。

还要考虑使用“long”是否合适。这是一个非常大的数字。仅当您认为您的表中可能有超过 20 亿个条目时才需要它。我很少使用它们。

GUID 也很难使用和调试。说“客户记录 10034 有问题，弗兰克，去看看”比说“{2f1e4fc0-81fd-11da-9156-00036a0f876a} 有问题...”容易得多。在需要时输入查询。

哦，您不会两次获得相同的 GUID。众所周知，它发生在非常大的、断开连接的系统上，所以这是需要考虑的事情，尽管我不会在大多数应用程序中为它设计。

GUID 何时合适

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

在某些 ORM 场景中，GUID 还允许您关联实体而不将它们持久化到数据库中。Linq to SQL（我相信 EF）没有这个问题，尽管有时您可能被迫将更改提交到数据库以获取密钥。

如果您在客户端上创建 GUID，则由于您创建的 GUID 不是连续的，因此插入性能可能会因数据库上的页面拆分而受到影响。

我的建议

这里有很多东西要考虑。我的投票是不使用它们，除非你有一个令人信服的用例。如果性能确实是您的目标，请将您的表保持小。保持你的领域小。保持你的数据库索引小而有选择性。

于 2010-02-09T11:51:47.197 回答
3

SIZE: Long 是 8 个字节 Guid 是 16 个字节

GUID绝对 具有唯一性的可能性很高， 并且最适合用于识别数据库中的单个记录。

long (Identity in DB)，可能表示表中的唯一记录，但您可能在一个或多个不同的表中具有由相同 ID (Identity) 表示的记录，如下所示：

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 相同的值

看看这里

于 2010-02-09T11:26:01.063 回答
2

Guid 使在 API 中创建“新”实体变得更加容易，因为您只需为其分配 Guid.NewGuid() 的值。不依赖数据库中的自动递增键，因此这可以更好地将域模型与底层持久性机制分离。

不利的一面是，如果您在 SQL Server 中使用 Guid 作为聚集索引，则插入变得昂贵，因为很少将新行添加到表的末尾，因此需要经常重建索引。

另一个问题是，如果您从这样的数据库中执行选择而不指定明确的顺序，您会以基本上随机的顺序得到结果。

于 2010-02-09T11:30:02.160 回答