24

我正在构建一个数据库，该数据库将存储有关一系列对象（例如科学论文、标本、DNA 序列等）的信息，这些对象都在线存在并且可以通过 URL 或诸如DOI之类的标识符来识别. 使用这些 GUID 作为对象的主键似乎是一个合理的想法，并且我在使用 GUID 的 md5 哈希时遵循了美味和Connotea 。如果您将鼠标悬停在美味或 Connotea 书签中的编辑或删除按钮上，您将在浏览器状态栏中看到 md5 哈希。例如，http://stackoverflow/的书签是

http://delicious.com/url/e4a42d992025b928a586b8bdc36ad38d

其中 e4a42d992025b928a586b8bdc36ad38d a 是http://stackoverflow/的 md5 哈希值。

有人对这种方法的优缺点有看法吗？

对我来说，这种方法的一个优点（与使用由数据库本身生成的自动递增主键相反）是我必须在对象之间做很多链接，并且通过使用 md5 哈希，我可以将这些链接外部存储在一个文件中（例如，作为数据挖掘/抓取的结果），然后将它们批量导入数据库。同样，如果必须从头开始重建数据库，则指向对象的 URL 不会更改，因为它们使用 md5 哈希。

我欢迎任何关于这听起来是否合理的想法，或者是否有其他（更好的？）方法来做到这一点。

4

7 回答 7

12

It's perfectly fine.

Accidental collision of MD5 is impossible in all practical scenarios (to get a 50% chance of collision you'd have to hash 6 billion URLs per second, every second, for 100 years).

It's such an improbable chance that you're trillion times more likely to get your data messed up due to an undetected hardware failure than due to an actual collision.

Even though there is a known collision attack against MD5, intentional malicious collisions are currently impossible against hashed URLs.

  • The type of collision you'd need to intentionally collide with a hash of another URL is called a pre-image attack. There are no known pre-image attacks against MD5. As of 2017 there's no research that comes even close to feasibility, so even a determined well-funded attacker can't compute a URL that would hash to a hash of any existing URL in your database.

  • The only known collision attack against MD5 is not useful for attacking URL-like keys. It works by generating a pair of binary blobs that collide only with each other. The blobs will be relatively long, contain NUL and other unprintable bytes, so they're extremely unlikely to resemble anything like a URL.

于 2008-11-13T22:44:25.560 回答
8

在浏览了更多stackoverfow之后，我发现了一个较早的问题GUID / UUID数据库键的优点和缺点，它涵盖了这个领域的大部分内容。

于 2008-10-21T09:02:22.503 回答
1

多个字符串可以产生相同的 md5 哈希。主键必须是唯一的。所以使用散列作为主键是不好的。更好的是直接使用 GUID。

是适合在 URL 中使用的 GUID。当然。这是我使用 Java 创建的 GUID（实际上是 UUID）：1ccb9467-e326-4fed-b9a7-7edcba52be84

网址可以是：

http://example.com/view?id=1ccb9467-e326-4fed-b9a7-7edcba52be84

它很长，但完全可用，并达到了您的描述。

于 2008-10-21T09:07:07.267 回答
0

也许这个文档是你想阅读的东西：

http://www.hpl.hp.com/techreports/2002/HPL-2002-216.pdf

于 2008-10-21T08:39:35.310 回答
0

通常有很多不同的 url 指向同一个页面。 http://example.com/ example.com http://www.example.com/ http://example.com/index.html http://example.com/。 https://example.com/ 等。

这对您来说可能是也可能不是问题。

于 2008-10-21T08:49:32.387 回答
0

MD5 被认为已弃用 - 至少出于加密目的，但我建议仅使用 md5 与现有东西向后兼容。当我们确实有其他没有（至少）被破坏的哈希算法时，你应该有充分的理由使用 md5。

我在该方法中看到的问题：

  • 重复的对象，因为 url 标识符不同（如 arend 所述）
  • 网址变化

后者可能很重要——这可以像删除和添加一样简单地完成。也就是说，如果这些 id 在数据库之外永远不可见/不可存储。（就像作为 URL 的组成部分一样。）

我想这些对于 DOI 来说不会是问题。

它如何与非自动编号整数 id 设置一起工作，但离线插入器代理在哪里创建数字？（可以使用专用的数字范围吗？）如果两个用户独立添加相同的 url，可能会出现重复问题？

于 2009-08-03T11:34:52.490 回答
-1

md5 散列几乎是唯一的，但并非完全唯一，因此不要将其用作主键。它因加密使用而折旧。密钥冲突的可能性较小，但如果你有数十亿行的相当大的数据库，仍然有一些冲突的机会。如果您坚持使用哈希作为主键，请使用其他更好的哈希。您不能对主键使用非唯一值。如果您有很大的桌子，请不要使用它。如果你有小桌子，你可能会使用它，但不推荐。

于 2016-02-27T04:57:01.880 回答