From : http://napkindrawing.blogspot.com/2009/01/database-design-uuid-vs-integer-auto.html
We’re doing some major database design at work and I raised the possibility of using UUIDs for all our surrogate keys as opposed to the traditional per-table auto-incremented integer or sequence. I personally prefer them, and we also have some special setup and needs that might benefit from them. We have distinct databases per client, where some “partners” span multiple clients (databases), I see this aiding in reporting across databases. We also have a need for replication, possibly multi-master replication as we’re thinking about segregating bulk data-processing (read+write) and daily usage (also read+write).
In the last few years, for my personal projects and some work projects, I’ve switched to using official and ghetto mini-UUIDs wherever auto-generated keys are used. For me, there wasn’t a single revelation, or one amazing article or book that changed my mind; it was more of a gradual annoyance with simplistic database-generated keys.
My reasons have primarily been:
I initially started using a simplistic random 16-digit alphabetical string to get the benefits described above, without having to deal with full-on 32 or 36 character UUIDs whilst programming and debugging. These are currently in use on my web site, for example:
These are generated in application code by a function that weights letter choices according to their frequency in the English language, so you end up with almost pronounceable keys. In the database all surrogate key columns have a default which produces hexadecimal digits if the surrogate key is not specified. This has been helpful for debugging and development, though given the weighting of the letters in English and the Birthday Paradox, I wouldn’t feel comfortable using this scheme on any large (billions of records) databases. Plus it’s completely non-standard and rather silly - you could have a “random” key like “ohhhbuttbutthaha”.
My last project at work used actual UUIDs as generated byHibernate’s UUIDHexGenerator, and the development overhead of - GOSH! - 32 character IDs was nonexistant. Even dealing with handwritten queries whilst testing, debugging and data analysis were much simpler when you don’t have to remember which “17” you’re looking for in a fresh database.
The main complaints googling for “uuid database” seem to be around adversely affected indexes where uuids are added in random numerical order to clustered indexes - which would seem to be addressable by using a timestamp-prefixed value, a simple “reverse(uuid())” in MySQL, for example.
I’m of the opinion that the added hardware+software burden of supporting 32 byte keys is moderate to trivial given modern hardware, and the benefits described above are enough of a reason to switch all instances of generated keys to be UUIDs
However: in android: