MD5 hash as artificial keys

I'm seeing lots of applications using hashes as surrogate keys instead of plain integ开发者_如何学Cers. I can't see any good reason for this kind of design.

Given most UUID implementations are just hashed timestamps, why so many database designers choose them for application-wide surrogate keys?

---

A hash allows more efficient comparisons between potentially large data values - in joins for example. i.e. the comparison of HASH(LargeObjectA)=HASH(LargeObjectB). If the hashed values are documents in a table of a document management system for example then it may be more efficient to compare hashes than documents.

Most DBMSs have limits on the storage size of a key, so a hash may be one alternative workaround for implementing larger keys.

Hashes can also be used to optimise storage by splitting data into logical partitions that are evenly distributed across a data set.

---

If the data backend for an application is made out of multiple distributed databases, using incremented integer ids might lead to duplicated values. UUIDs are guaranteed to be unique not only inside the application but outside it as well (which might be helpful when joining with external data).

It is true that using different id seeds for the different databases in the system would solve the uniqueness problem for integers, but managing such an approach would be more difficult.

---

Uniqueness across servers? Using plain integers wouldn't work well in that situation.