当前位置：文江博客话题详情

long vs Guid for the Id (Entity)，有什么优缺点

发布于 2024-08-21 04:30:01 字数 110 浏览 2 评论 0原文

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

原文

分享到QQ

分享到微博

如果你对这篇内容有疑问，欢迎到本站社区发帖提问参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。

发布评论

需要登录才能够评论，你可以免费注册一个本站的账号。

轮廓§ 2024-08-28 04:30:01

何时 GUID 可能不合适

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

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

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

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

GUID 何时适用

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

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

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

我的建议

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

When GUIDs can be Inappropriate

GUIDs are almost always going to be slower because they are larger. That makes your indexes larger. That makes your tables larger. That means that if you have to scan your tables, either wholly or partially, it will take longer and you will see less performance. This is a huge concern in reporting based systems. For example, one would never use a GUID as a foreign key in a fact table because its length would usually be significant, as fact tables are often partially scanned to generate aggregates.

Also consider whether or not it is appropriate to use a "long". That's an enormously large number. You only need it if you think you might have over 2 BILLION entries in your table at some point. It's rare that I use them.

GUIDs can also be tough to use and debug. Saying, "there's a problem with Customer record 10034, Frank, go check it out" is a lot easier than saying "there's a problem with {2f1e4fc0-81fd-11da-9156-00036a0f876a}..." Ints and longs are also easier to type into queries when you need to.

Oh, and it's not the case that you never get the same GUID twice. It has been known to happen on very large, disconnected systems, so that's something to consider, although I wouldn't design for it in most apps.

When GUIDs can be Appropriate

GUIDs are the appropriate when you're working with disconnected systems where entities are created and then synchronized. For example, if someone makes a record in your database on a mobile device and syncs it, or you have entities being created at different branch offices and synced to a central store at night. That's the kind of flexibility they give you.

GUIDs also allow you the ability to associate entities without persisting them to the database, in certain ORM scenarios. Linq to SQL (and I believe the EF) don't have this problem, though there are times you might be forced to submit your changes to the database to get a key.

If you create your GUIDs on the client, it's possible that since the GUIDs you create are not sequential, that insert performance could suffer because of page splits on the DB.

My Advice

A lot of stuff to consider here. My vote is to not use them unless you have a compelling use case for them. If performance really is your goal, keep your tables small. Keep your fields small. Keep your DB indexes small and selective.

回复收藏 0 原文

哽咽笑 2024-08-28 04:30:01

尺寸：
长为8字节
Guid 是 16 字节

GUID 绝对 具有唯一性的高概率，最适合用于识别数据库中的各个记录。

long（数据库中的身份），可能表示表中的唯一记录，但您可能在一个或多个不同的表中具有由相同 ID（身份）表示的记录，如下所示：

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

看看这里

SIZE:
Long is 8 bytes
Guid is 16 bytes

GUID has ~~definitely~~ high probability for going to be unique and is best to use for identification of individual records in a data base(s).

long (Identity in DB), might represent a unique record in a table but you might have records represented by same ID (Identity), in one or more different table like as follows:

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

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

both can return same value, but in case of 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 ='

you can rarely have same value as id returned from two tables

Have a look here

回复收藏 0 原文