title: Pros and cons of using md5 hash of URI as the primary key in a database
body: <p>I'm building a database that will store information on a range of objects (such as scientific papers, specimens, DNA sequences, etc.) that all have a presence online and can be identified by a URL, or an identifier such as a <a href="http://www.doi.org/" rel="noreferrer" title="DOI">DOI</a>. Using these GUIDs as the primary key for the object seems a reasonable idea, and I've followed <a href="http://delicious.com/" rel="noreferrer" title="delicious">delicious</a> and <a href="http://www.connotea.org" rel="noreferrer" title="Connotea">Connotea</a> in using the md5 hash of the GUID. You'll see the md5 hash in your browser status bar if you mouse over the edit or delete buttons in a delicious or Connotea book mark. For example, the bookmark for <a href="http://stackoverflow/" rel="noreferrer">http://stackoverflow/</a> is </p>
  
  <pre><code>http://delicious.com/url/e4a42d992025b928a586b8bdc36ad38d
  </code></pre>
  
  <p>where  e4a42d992025b928a586b8bdc36ad38d ais the md5 hash of <a href="http://stackoverflow/" rel="noreferrer">http://stackoverflow/</a>.</p>
  
  <p>Does anybody have views on the pros and cons of this approach?</p>
  
  <p>For me an advantage of this approach (as opposed to using an auto incrementing primary key generated by the database itself) is that I have to do a lot of links between objects, and by using md5 hashes I can store these links externally in a file (say, as the result of data mining/scraping), then import them in bulk into the database. In the same way, if the database has to be rebuilt from scratch, the URLs to the objects won't change because they use the md5 hash.</p>
  
  <p>I'd welcome any thoughts on whether this sounds sensible, or whether there other (better?) ways of doing this.</p>