Why I use UUIDs for primary/foreign keys

[eluser]Dam1an[/eluser]
[quote author="wiredesignz" date="1244487140"]No UUID I create can be created by anyone else ever again.[/quote]

Sorry but that's wrong... maybe it won't be repeated any time soon, but there is a finite number (all be it a very large one).

It's the same with MD5, for a long time, some people thought that md5 will always give you a unique hash, but thats not the case (before you accuse me of being clueless, note I said 'some people thought', not 'I thought')

[eluser]slowgary[/eluser]
No it isn't. UUID generation is partially based on time, so a UUID you made 20 minutes ago will never have been made again whether you made it or not, right?

Also, I'm sure a UUID that you create could be duplicated in the world somewhere. It's not as if UUIDs are registered in some centralized system where they're only allow to be used once. Part of the probability of duplication is likely based on the fact that not every piece of software in the world is working off of one database, otherwise UUIDs would certainly be duplicated.

If I must, I will engineer a million unit bot-net to generate constant UUIDs and register them in a data center the size of Google's, just to calculate the frequency of duplication, thus proving you and many others from the cult of UUID wrong. ;-P

[eluser]wiredesignz[/eluser]
@Damian, stop right now.

"After generating 1 billion UUIDs every second for the next 100 years, the probability of creating just one duplicate would be about 50%"

That is 1000 million UUID's per second.

[eluser]Dam1an[/eluser]
WD, I'm well aware of that statistic, I have been following this thread
All I was saying is that is is potentially possible to get a duplicate, as it's not gauranteed to be unique, unlike an auto incrementing ID

[eluser]wiredesignz[/eluser]
Buddy, you won't get a duplicate.

[eluser]jedd[/eluser]
Uniqueness (or degrees of same) isn't my concern - my problem remains that I can't understand the asserted benefits of having a unique UUID as a key across all your tables. I can grok the benefits if it's across two very similar databases that you may one day want to merge, but that has to be an edge case for most people.

The earlier suggestion was for logging activity within the db - something that I'm going to do on my project at some point - but AFAICT you either have to:
a) search through all tables looking for the UUID (this seems expensive) or
b) record the table with the UUID (this seems functionally equivalent to auto-inc ID + table name).

[eluser]slowgary[/eluser]
50% seems pretty probable. Also, I bet as time passes after that 100 years, the percentage begins to increase exponentially.

I don't know about you guys, but I write my software to last through the millennial reign of Jesus Christ, cause I plan to be around at that time.

[eluser]wiredesignz[/eluser]
Slowgary is proof of software retardation.

[eluser]sl3dg3hamm3r[/eluser]
[quote author="slowgary" date="1244489327"]50% seems pretty probable. Also, I bet as time passes after that 100 years, the percentage begins to increase exponentially.[/quote]

Au contraire: it'll flatten.

[eluser]slowgary[/eluser]
Thanks, I love you too.

And I'm just kidding when I write about UUID duplication. It's unlikely and we really shouldn't worry about it. I think though if you're using UUIDs, you should still code to handle a duplicate.

Jedd's right, the duplication conversation is moot. I still am not sold on it for every case, but I may need to use it somewhere eventually. I think I'd probably opt for using a UUID as a secondary index though.