|
Searching for the number of possible GUIDs (answering questions in the forum section) I struggled over this amusing SO Thread where they are seriously discussing how the non-unique nature of a GUID can be proofed.
Enjoy[^]
Edit -> Here is my answer to the said question (can you think of a creative one yourself?):
Quote: A Guid is 128 bit. Therefore you would have to generate 2^128 + 1 GUIDs to encounter a single GUID twice.
A thread on StackOverflow.com[^] says that you would need about 10790283070806014188970 years to encounter a single GUID twice, assuming your program does nothing else than creating GUIDs and runs at a processor speed of 1 GhZ, without any interruption by CPU power eaten by other programs or the operating system itself.
As you probably can think now, encountering the same GUID twice would be very bad luck and can safely considered as being unrealistic.
People becoming wiser in order to notice the stupid things they did back in the young days. This doesn't mean that they really stop doing those things. Wise people still do stupid things, only on purpose.
modified 22-Oct-13 7:30am.
|
|
|
|
|
I have always argued (mostly unsuccessfully) that any system that aims to be reliable cannot depend on the uniqueness of GUIDs.
There is no problem that they solve that cannot also be solved in a way that is guaranteed to be reliable (although the solution may be more complex)
Sure, it may not happen, but it can happen.
|
|
|
|
|
Yep, I always work on the principal that a GUID may be duplicated so I add Ticks since the Epoch or something like that to my GUIDs because Ticks should only ever increase. The chances of getting the exact same ticks in milliseconds AND a duplicate GUID are not gunna happen!
you're welcome 
|
|
|
|
|
You don't need to add a surrogate key containing a “tick”, because GUIDs already have such a field.
|
|
|
|
|
Adding it where?
Guids aren't always "increasing". so adding an increasing value to a random value doesn't mean you won't get a duplicated outcome.
|
|
|
|
|
Marco Bertschi wrote: A Guid is 128 bit. Therefore you would have to generate at most 2^128 + 1 GUIDs to encounter a single GUID twice.
I thought developers were supposed to be logical!
Your statement screams "Does not compute, Will Robinson!" at me!
The minimum, of course, is two.
I wanna be a eunuchs developer! Pass me a bread knife!
|
|
|
|
|
Or, of coutrse he could have said
Marco Bertschi wrote: A Guid is 128 bit. Therefore you would have to generate 2^128 + 1 GUIDs to guarantee encountering a single GUID twice.
The only instant messaging I do involves my middle finger.
English doesn't borrow from other languages.
English follows other languages down dark alleys, knocks them over and goes through their pockets for loose grammar.
|
|
|
|
|
While you smart arses are arguing the toss I've just seen another duplicate GUID pass by. 
If there is one thing more dangerous than getting between a bear and her cubs it's getting between my wife and her chocolate.
|
|
|
|
|
Did it include the characters S, S, N, N, L, L, L, I, I, E, E, E, and E?
I wanna be a eunuchs developer! Pass me a bread knife!
|
|
|
|
|
I'm sure our dearly departed forum friend Leslie would confirm that. 
If there is one thing more dangerous than getting between a bear and her cubs it's getting between my wife and her chocolate.
|
|
|
|
|
You sure?
They are a lot like snowflakes: if you look at the fine detail they aren't the same.
The only instant messaging I do involves my middle finger.
English doesn't borrow from other languages.
English follows other languages down dark alleys, knocks them over and goes through their pockets for loose grammar.
|
|
|
|
|
Quote: They are a lot like snowflakes:
Funny you bring that up. Recently a scientist claimed to have found many duplicates after cataloging many, many snowflakes.
Of course they aren't unique.
There are only 10 types of people in the world, those who understand binary and those who don't.
|
|
|
|
|
Does that include artificial snowflakes?  
|
|
|
|
|
To be fair though, snowflakes are only 64 bit
|
|
|
|
|
Yikes! It's like encountering your doppelgänger in the street.
I may not last forever but the mess I leave behind certainly will.
|
|
|
|
|
With GUID we talk about probability not certainty.
Even we have a GUID generator that really generates unique id, at the moment we run it in multiply locations we lost event the theory of uniqueness...
I'm not questioning your powers of observation; I'm merely remarking upon the paradox of asking a masked man who he is (V).
|
|
|
|
|
I still try discourage everyone from using GUID's if it's not truly necessary.
1. Waste of disk space, if an 32bit integer is sufficient why use a GUID?
2. Waste of processing power, more expensive to create, more expensive to compare against etc.
3. GUID is way more difficult to read for humans
Sure there are uses for it but in most cases you're perfectly fine without them.
|
|
|
|
|
Nicholas Marty wrote: 3. GUID is way more difficult to read for humans
So what? IDs are meant to be meaningless; so that's a good thing. Even with integers you'll likely wind up just copying-and-pasting anyway.
Or do this:
00000000-0000-0000-0000-000000000001
00000000-0000-0000-0000-000000000002
00000000-0000-0000-0000-000000000003
00000000-0000-0000-0000-000000000004
00000000-0000-0000-0000-000000000005
|
|
|
|
|
But...but...integers fit so much more nicely into a query string!
*duck and cover*
Seriously though, one of the few uses I've found for GUIDS is to allow the keys in your tables to be easily moved between different databases, for instance to move between a production and test DB. But otherwise integers are more efficient and easier to work with.
As for the uniqueness debate, who cares? Raise your hand if you have ever seen a duplicate GUID pop up in a real-world situation. It's like arguing about the randomness of pseudo-random number generators, it's a moot point for almost all real-world implementations.
If you're generating thousands of GUIDs per second in a system that you expect to be around for centuries, then maybe you should worry about it. Otherwise, it's like worrying about the server being taken out by a meteor hit. And even if you're unlucky enough to have a collision, you'd have to have a pretty fragile system for that to be a huge disaster; you'll probably have a dupe showing up in a join somewhere, not that hard to find and fix.
|
|
|
|
|
Yup; my previous employer offered both standalone installations and a SAAS model where we hosted, and some of the primary keys were ints. When a client decided it was better to go from standalone to SAAS, merging was a giant PITA.
|
|
|
|
|
They are also good for situations when you want an unpredictable value, such as a reference in a link for proving an email address.
|
|
|
|
|
StatementTerminator wrote: easily moved between different databases
Yes indeed.
Reminds me of one place I worked where identities were used and the only way to view PROD data was to have a tool copy the data to a DEV database -- but the tool didn't allow the IDs to be copied  , the copied rows all had new IDs that didn't match PROD.
My argument isn't entirely against integers, but auto-increment integers over which the developer has no control. 
StatementTerminator wrote: integers are more efficient and easier to work with
My experience has been the opposite.
StatementTerminator wrote: As for the uniqueness debate, who cares?
'Xactly
|
|
|
|
|
Guids are great for building object relationships client side without a need to hit a database to get the next available integer. Users should never see a Guid.
|
|
|
|
|
It's a random number from a limited domain. Ask enough numbers, and you'll encounter the same number sooner or later - one doesn't need much math to explain the logic.
Bastard Programmer from Hell 
If you can't read my code, try converting it here[^]
|
|
|
|
|
That's why I always repetitively hash and bitmask things until I end up with one byte.
And it has to be a human-readable byte, too, for those pesky tech support calls. 
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
