我正在构建一个数据库，该数据库将存储一系列对象（如科学论文，标本，DNA序列等）的信息，这些对象都具有在线状态，并且可以通过URL或标识符识别作为DOI。使用这些GUID作为对象的主键似乎是一个合理的想法，我使用了delicious和Connotea来使用GUID的md5哈希。如果将鼠标悬停在美味或Connotea书签中的编辑或删除按钮上，您将在浏览器状态栏中看到md5哈希。例如，http://stackoverflow/的书签是
http://delicious.com/url/e4a42d992025b928a586b8bdc36ad38d
其中e4a42d992025b928a586b8bdc36ad38d是http://stackoverflow/的md5哈希值。
有没有人对这种方法的利弊有看法？
对我而言，这种方法的优势（与使用数据库本身生成的自动递增主键相反）是我必须在对象之间进行大量链接，并且通过使用md5哈希，我可以在外部存储这些链接在文件中（例如，作为数据挖掘/抓取的结果），然后将它们批量导入数据库。同样，如果必须从头开始重建数据库，则对象的URL不会更改，因为它们使用md5哈希。
我欢迎任何关于这听起来是否明智的想法，或者是否还有其他（更好的？）方法。
答案 0 :(得分：10)
完全没问题。
在所有实际情况下，MD5的意外碰撞是不可能的（为了获得50％的碰撞几率，您必须每秒散布6 十亿 URL 每秒 ，100年）。
这是一个不太可能的机会，由于未检测到的硬件故障比实际碰撞造成数据混乱的可能性高出几倍。
即使存在针对MD5的已知冲突攻击，目前也无法针对散列网址进行故意恶意冲突。
您需要故意与其他网址的哈希冲突的类型称为前映像攻击。没有已知的针对MD5的前映像攻击。截至2017年，没有任何研究甚至接近可行性，因此即使是一个资金严重的攻击者也无法计算一个会散列到数据库中任何现有URL的哈希值的URL。
针对MD5的唯一已知碰撞攻击对攻击类似URL的密钥没有用。它的工作原理是生成一对只与彼此冲突的二进制blob 。 blob将相对较长，包含NUL和其他不可打印的字节，因此它们极不可能像URL一样。
答案 1 :(得分：8)
在浏览stackoverfow之后，我发现了一个早期的问题Advantages and disadvantages of GUID / UUID database keys，其涵盖了大部分内容。
答案 2 :(得分：1)
多个字符串可以生成相同的md5哈希。主键必须是唯一的。因此使用哈希作为主键并不好。更好的是直接使用GUID。
GUID是否适合在URL中使用。当然。这是一个使用Java创建的GUID（实际上是一个UUID）：1ccb9467-e326-4fed-b9a7-7edcba52be84
网址可能是：
http://example.com/view?id=1ccb9467-e326-4fed-b9a7-7edcba52be84
它很长但很完美，可以实现你描述的内容。
答案 3 :(得分：1)
MD5被认为已被弃用 - 至少出于加密目的，但我建议仅使用md5向后兼容现有内容。当我们确实有其他哈希算法没有（至少还有）被打破时，你应该有充分的理由选择md5。
我在方法中看到的问题：
后者可能是重要的 - 这可以像删除和添加一样简单地完成。也就是说，如果这些ID在数据库之外永远不可见/可存储。 （与URL的组成部分一样。）
我想这些对于DOI来说不会有问题。
如何使用非自动编号整数ID设置，但脱机插入器代理创建数字的位置？ （也许可以使用专用的数字范围？） 如果两个用户独立添加相同的网址，可能会出现重复问题吗？
答案 4 :(得分：0)
也许这篇文章是您想要阅读的内容：
答案 5 :(得分：0)
通常有很多不同的网址指向同一页面。 http://example.com/ example.com http://www.example.com/ http://example.com/index.html http://example.com/。 https://example.com/ 等
这对您来说可能是也可能不是问题。
答案 6 :(得分：-1)
md5哈希几乎是唯一的，但并不是完全独特的，所以不要将它用作主键。它是为加密使用而折旧的。密钥冲突的可能性较小，但如果您拥有数十亿行的大型数据库，则仍有可能发生冲突。如果你坚持使用hash作为主键使用其他更好的hash。您不能对主键使用非唯一值。 如果你有一个很大的桌子，不要使用它。如果您有小桌子，可以使用它，但不建议使用。