We use GUIDs extensively in our database design; Business Object properties provide Guid.Empty GUIDs for DB null values and null is always saved to the database if the value is Guid.Empty.
Apart from Guid.Empty (00000000-0000-0000-0000-000000000000) how likely is it that a GUID will be generated with all the same characters e. g.: 11111111-1111-1111-1111-111111111111
Just considering using GUIDs like these for specific values.
About as likely as any other randomly generated guids will collide. So, highly unlikely.
Though, you may want to rethink using guids to "store" data like that. They are really used to uniquely identify objects and components.
Very, very low. The GUID format includes a few bits identifying the scheme. If you'd "generate" them yourselves, the GUID scheme would most likely be wrong.
It's as likely as any other Guid.
If you insert it in the database (even with some special meaning) then you might also ensure that it's unique with an appropriate constraint.
Approx 1 in 5,316,911,983,139,663,491,615,228,241,121,400,000
So I think you're safe.
Source: http://msdn.microsoft.com/en-us/library/aa446557.aspx
GUID's are usually generated using an alorithm, rather than being a genuinely random string of hex characters, so if you can be sure what algorithm is being used to generate them you can then be sure if the GUIDs you want to use as "magic numbers" are going to collide with generated ones.
The Wikipedia page on GUIDs has a decent amount of information regarding the algorithms that are used, so that may be able to give you a definitive answer. Or, running Reflector over the Guid.NewGuid() method in the .net framework.
Why use a specially designed GUID? Beside the recognizable aspect, why not just use a properly generated GUID? (You know it will be unique, that is the point)
In short: For GUID generated according to the published standards and specifications it simply can't happen. A GUID has a structure and some of the fields actually have a meaning. What's more, .NET generates GUIDs of version 4, where it absolutely can't happen. They are defined in a way that there won't be such a GUID. For details, see below ;-)
There are five to seven bits which are the main pitfall here. Those are the version identifier (the first four bits of part three) and the variant field specifying what variant of GUID this is.
The version can be anything between 1 and 5 currently. So the only valid hex digits for which we could get such a GUID at this point are—obviously—1 through 5.
Let's dissect the versions a little:
8, 9, A or B. This contradicts the 4 for the version number.So far we ruled out version 4 as impossible, others as highly unlikely. Lets take a look at the variant field.
The variant field specifies some bit patterns for backwards compatibility (x is a don't care), namely:
0 x x Reserved. NCS backward compatibility.
1 0 x The only pattern that currently can appear
1 1 0 Reserved, Microsoft Corporation backward compatibility
1 1 1 Reserved for future definition.
Since this pattern is at the very start of the fourth part, this means that the most significant bit is always set for the very first hex digit of the fourth part. This means that this very digit can never be 1, 2, 3 or 5. Not counting already generated GUIDs, of course. But those with the MSB set to 0 happen to be either v1 or v2. And the timestamp part of those means that they would have to be generated some millenia in the future for that to work out.
Your question has already been answered, but I thought I'd be pragmatic here.
1) You will only give yourself 8 "hard-coded" options using this convention.
2) You could just create a real GUID for each these "special" cases instead of hand-cranking them. That way, it is guaranteed to be unique and you'll be able to have more than 8.
That's not a direct answer, I know, but it is probably a sensible suggestion given your intentions.
For my last company, we used guids as primary keys for tables for all of our databases. In all we instantiated more than 1,000,000,000 objects and never had any issues.