Posted on 11/9/08 by Felix Geisendörfer
what are UUIDs? Well according to the Wikipedia:
A Universally Unique Identifier (UUID) is an identifier standard used in software construction, standardized by the Open Software Foundation (OSF) as part of the Distributed Computing Environment (DCE).
In English that would roughly translate to really long random strings. So random in fact that Wikipedia thinks:
After generating 1 billion UUIDs every second for the next 100 years, the probability of creating just one duplicate would be about 50%
So why should you care and maybe even use those UUIDs? I mean there are certainly reasons against using them. Ever tried to memorize a bunch of UUIDs? Give it a shot:
48c907b0-b8ac-4161-84c9-4fbf1030b5da 48c907b0-dc38-475c-a9c4-4a2e1030b5da 48c907b0-f088-44ae-8be5-4e811030b5da
When it comes to primary keys you might miss the ease with which one can remember auto incrementing values. But hang on, with a bit of copy & paste one can get over this inconvenience and carry those values around.
But why should you go through that trouble? The answer can largely be found in their uniqueness. With UUIDs, you can give an identifier to any object in the real world. This id you give it is guaranteed to not have been used for labeling any other object in the universe so far. Guaranteed in this context means you are more likely to win the lottery without buying lottery tickets than generating a duplicate UUID.
This is an amazing property for several reasons. Imagine a fairly real world task of having to join the blog posts of two previously separate sites into a single new one. Back when Tim and I did that for this blog we had to re-index all our blog post ids as well as all foreign keys pointing to them. Why? Because we both had given out the same auto incrementing ids to different blog posts. If we (wordpress) had used UUIDs, merging our two blogs (or any other sets of data) would have been magnitudes easier.
And there is more. If you want to create polymorphic associates than UUIDs are going to make that a lot easier for you in CakePHP. Just create a table called 'comments' and give it a belongsTo of [Photo, Post, User]. But instead of creating a foreign key field for each model, you get away with just creating a single foreign_id field and setting that up as the foreign key for all the belongsTo associations. Since the UUID the foreign_id points to is unique across tables, you don't even have to track what model / table it actually belongs to. This avoids a more complex query and leads to improved performance for the setup. (You might still want to populate Comment.model just so you know where the link goes to without doing the actual lookup).
Last but not least there is another advantage hidden in the randomness of those ids. By not having your ids follow any pattern, an attacker won't be able to iterate through your databases records without you giving him a map of primary ids for it. This in itself doesn't automatically make your application secure, but it lessens the damage that is likely to be done if a permission bug is exploited.
Anyway, I'm sure I forgot a bunch of reasons and I am also looking forward to people sharing their concerns on performance and the concept itself. In the meantime just know that CakePHP will automatically generate UUID keys if your primary key is a char(36) field.
-- Felix Geisendörfer aka the_undefined
You can skip to the end and add a comment.
This post is too old. We do not allow comments here anymore in order to fight spam. If you have real feedback or questions for the post, please contact us.