"Just to chime in here: First off, how are you going to generate them? How will you avoid collisions? Why should it be necessary to using that much storage space for a primary key and what's the reason for not using blazingly-fast integers?..."
chance of collision is slim... it's a truly large amount of bits... There's libuuid for linux, and builtin functions for windows to create them. I personally have come to like UUIDs... as I can build large related transactions of data without storing them in the database and retrieving what the auto-increment ID is to fixup the other related rows. I can build a complex transaction set without touching the database, and only on the slim chance of a collision update keys. (haven't yet ever hit that fixup code except in test cases where I purposely chose bad keys) Using the birthday paradox calculation( http://en.wikipedia.org/wiki/Birthday_problem) , it takes "only after generating 1 billion UUIDs every second for the next 100 years, the probability of creating just one duplicate would be about 50%." ( http://en.wikipedia.org/wiki/Universally_unique_identifier) and that's not even a real 50%... Most tools support copy and paste if you really want to use a key and select rows joined with a separate statement. Rarely do I ever have to worry about having to 'remember a number' to do a select... I just do my normal select on criteria with appropriate joins and forget the keys; or select from appropriate views that already have the joins... Some databases perform better if you use a 'sequential uuid' (MS SQL) the others don't seem to care one way or another for performance... a squential UUID uses the first long as like milliesecond timestamp that is always forward-going, and retains the random parts for everything else (other than the digit that's supposed to idenfity the source of the UUID creator... so even changing that digit to not '4' puts out out of collision of most other algorithms. Once upon a time part of the standard was 'use the ethernet MAC address as part of the number' but that was seen as an exploit that gave unscrupulous people information, this was later patched and removed and only existed for a few years near the turn of the century (a decade+ ago). Oh and the other feature! of UUIDs is merging databases... if I have a database deployed to 15 customers, each with their own ORGID I can easily throw them in the same database without worrying about fixing up primary keys and all records related to those keys. Also given a badly designed schema, I can definitely tell what columns relate to other columns, as the primary keys will only show up once, and all other columns, even if badly named, can be matched that that's actually the source key they reference. --------- I find that generally those who say 'yuck, don't do that' have never done it. And those that have, will never go back to simple integers again.
