Linq:如何在数据库中存储 MD5 哈希列

发布于 2024-12-11 01:49:52 字数 153 浏览 0 评论 0原文

我需要在数据库中的 md5 哈希列上放置索引。我将在 md5 列上执行搜索。我打算将哈希存储为 CHAR(32),但我也看到了二进制列选项。将 md5 哈希值存储在二进制列或 char(32) 中会更好吗?我可以使用 Linq to Entities 查询二进制列吗?如果是这样,我该怎么办?

I need to put an index on a md5 hash column in the database. I will perform searches on the md5 column. I was going to store the hash as a CHAR(32) but I seen the binary column option as well. Will storing a md5 hash work better in a binary column or a char(32). Can i use Linq to Entities to query a binary column? If so, How would I go about this?

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

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

发布评论

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

评论(3

一个人的夜不怕黑 2024-12-18 01:49:52

如果您使用 SQLServer 或任何其他支持 128 位 GUID 类型的服务器...您可以使用 GUID 类型来表示 MD5 值。

由于 MD5 是 16 字节(128 位),因此您可以轻松地将其转换为 GUID。
要在 C# 中执行此操作,您可以使用 Guid 结构和/或手动编写简单的转换例程。

Guid 的格式为 xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx,其中 x 是十六进制字符,但在内部存储为 128 位整数,因此,它们占用的空间非常少,并且查询速度非常非常快!

GUIDS 的工作方式比 char 或二进制要好得多,它们是固定大小的,并且由于速度非常快且空间消耗低,因此在需要更多位时通常用作键\索引而不是 INT。

If you are using SQLServer or any other server that supports 128 bit GUID types... you can use the GUID type to express an MD5 value.

Since MD5 is 16 byte (128 bit) you can easily convert it to a GUID.
For doing that in C# you can use the Guid structure and\or write simple conversion routines by hand.

Guids are in the format xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx where x is an hexadecimal character, but are internally stored as 128 bit integers, so, they occupy very little amount of space and are very, very fast for queries!

GUIDS works much better than char or binary, they are fixed size and are often used as keys\indices instead of INT when more bits are needed due to their very high speed and low space consumption.

兲鉂ぱ嘚淚 2024-12-18 01:49:52

如果索引相同,则选择哪种类型并不重要,区别在于存储。二进制类型可能会更小,而 char 类型会将值编码为整数。实际上,最终我会使用 char,因为它比二进制文件更宽容。因此,除非您存储大量、数百万个,否则不会产生很大的影响。

至于LINQ,我不确定,但我很确定你可以,它只是字段而不是字段。这是我选择 char 的另一个原因,它使处理 linq 变得更容易。

If the indexing is the same it won't matter which type you select, the difference is going to be in the storage. The binary type will likely be smaller, whereas the char type will encode the values as integers. Really at the end of the day I'd use the char because it will be more forgiving then the binary. So unless you're storing a ton of these, millions of them, it's not going to make a big difference.

As for the LINQ, I'm not sure, but I'm pretty sure you can, it'll just be field instead of field. That's the other reason I'd go char, it makes dealing with linq easier.

旧人哭 2024-12-18 01:49:52

这实际上取决于您如何在代码中表示哈希值。如果它是字节数组,请继续使用二进制 DB 类型。如果它是一个字符串,请使用它。无论哪种方式,在某种程度上,它都是二进制数据,这只是计算机在向您显示数据时被告知解释它的方式。

It really depends on how you represent your hash in code. If it's a byte array, go ahead and use the binary DB type. If it's a string, use that. Either way, it's all binary data at some level, it's just how the computer is told to interpret it when showing the data to you.

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