GUID:varchar(36) 与 uniqueidentifier

发布于 2024-09-15 08:43:21 字数 326 浏览 2 评论 0原文

我正在使用一个将 GUID 值存储为 varchar(36) 数据类型的旧数据库:

CREATE TABLE T_Rows (
    RowID    VARCHAR(36) NOT NULL PRIMARY KEY,
    RowValue INT         NOT NULL
) 

INSERT T_Rows (RowID, RowValue) VALUES (NEWID(), 1)

我认为将 GUID 存储为唯一标识符会更好,因为它的大小只有 16 个字节,而不是 36 个字节。

有什么优点吗?将 GUID 存储为 varchar?

I'm working with a legacy database that stores GUID values as a varchar(36) data type:

CREATE TABLE T_Rows (
    RowID    VARCHAR(36) NOT NULL PRIMARY KEY,
    RowValue INT         NOT NULL
) 

INSERT T_Rows (RowID, RowValue) VALUES (NEWID(), 1)

I would assume that storing a GUID as a uniqueidentifier would be preferable since it's only 16 bytes in size as opposed to 36.

Are there any advantages to storing a GUID as a varchar?

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

扫码二维码加入Web技术交流群

发布评论

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

评论(5

浪漫人生路 2024-09-22 08:43:21

也许只是因为您可以从 SELECT 语句中“读取”它们(尽管我认为这不是特别有用,因为您可以在选择中使用函数来使 Uniqueidentifiers 可显示)。

如果表很大,每行节省 20 个字节是相当可观的。

Perhaps only the fact that you can 'read' them from a SELECT statement (although I don't think that's particularly useful as you can use a function in a select to make Uniqueidentifiers displayable).

If the table is large, saving 20 bytes per row is considerable.

本宫微胖 2024-09-22 08:43:21

我会使用 uniqueidentifier ,原因有很多,例如,

它会占用更少的空间;它是独一无二的,因此无法复制。它对于比较和特别与性能相关的问题以及容易获得唯一的默认值等要好得多。

我会使用 uniqueidentifier ,除非我出于非常具体的原因需要使用 varchar 。

I would go with uniqueidentifier for many reasons such as,

it will take less space; it's unique so it can not be duplicated. It's much better for comparisons and specially performance related issues as well as easy to get unique default value etc.

I would use uniqueidentifier unless I need to use varchar for very specific reason.

盗梦空间 2024-09-22 08:43:21

我相信 UNIQUEIDENTIFIER 是在 SQL Server 2000 中添加的,因此该应用程序可能最初是为 SQL Server 7 编写的,而 SQL Server 7 不支持它。但这当然只是猜测……

I believe UNIQUEIDENTIFIER was added in SQL Server 2000, so it's possible this application was originally written for SQL Server 7, which didn't support it. But that's just a guess, of course...

左秋 2024-09-22 08:43:21

如果您的数据库是 Oracle,那么旧版本 Oracle (9) 中原始数据索引的性能比索引 varchar(36) 字段要差得多。幸运的是,这种情况在 Oracle 10 和 11 中发生了变化。

If your database is Oracle then the performance of indexes for raw data in older version of Oracle (9) was much, much poorer than indexing a varchar(36) field. Luckily this has changed in Oracle 10 and 11.

想你的星星会说话 2024-09-22 08:43:21

绝对不是,因为我确信您知道遗留数据库经常存在设计缺陷:P 因为 GUID 是 16 字节,所以它可能会在数据库中占用 16 字节。每个条目您将获得 20 个字节

Absolutely not, as I'm sure you know legacy databases often suffer from design flaws :P Because GUID is 16 bytes, it might as well take up 16bytes in the database. You'll gain that 20 bytes per entry

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文