How are GUIDs generated in C#?
The algorithm is documented here: http://en.wikipedia.org/wiki/Globally_Unique_Identifier
A Guid is made up of 5 groups of Hexadecimal (0-9, A-F) characters.
An empty Guid has all of these set to 0.
These are random, and supposably non-repeatable on generation.
A .Net System.Guid
is just a 128-bit integer (16 bytes). Numbers and letters have nothing to do with it. You can use the ToString() method to see various "human-readable" versions of a Guid, which include numbers 0-9 and letters A-F (representing hex values), but that's all up to you how you want to output it.
The RFC here might shed some light on GUIDs for you. It does not answer your specific C# question.
A Guid is a unique number that has billions of permutations and is made up of a mixture of hexadecimal and numbers in groups. And it is generated based on the different factors, such as time, windows version, system resources such as hard disks, motherboards, devices and so on. A Guid is guaranteed to be unique. (Thanks ck!) I have not seen an instance where you do
Guid g = new Guid.NewGuid();Guid g = Guid.NewGuid(); /* Thanks Dave! */
where g
will have the same value in successive runs.
It is more commonly used for mutexes, an example would be to create a single instance of an application and by using a mutex with a guid guarantees the lifetime of the instance of the application.
Even, in some instances, it is used in the database but the method of using it is frowned upon.
Hope this helps, Best regards, Tom.
There are also other forms of GUID besides "random 16 bytes", as mentioned in the RFC. Some Microsoft products (SQL Server for instance) can optionally generate these "sequential GUIDs" which are based on a combination of "MAC address of first network card in the system + ever-increasing counter based on system time".
These "sequential GUIDs" have the nice property of always appending new records to the "end" of a database table when used as a database primary key with a clustered index. This helps prevent database index fragmentation and page splits.
If random GUIDs are used as database primary keys with clustered indexes, new records will be inserted randomly in the "middle" of a table from a physical allocation standpoint, which leads to index fragmentation and partially-full database pages over time.
Using sequential GUIDs still allows you to generate GUIDs independently on multiple systems and be confident there will not be any collisions (a property that you do not get using sequential integers as primary keys without allocating "ranges" or different seeds and increments to each system, which is an administrative nightmare in large distributed applications).
There is a really good article here that describeds how GUIDs are generated, and in particular why a substring of a guid is not guarenteed to be unique.
Basiclly a GUID is generated using a combination of
- The MAC address of the machine used to generate the GUID (so GUIDs generated on different machines are unique unless MAC addresses are re-used)
- Timestamp (so GUIDs generated at different times on the same machine are unique)
- Extra "emergency uniquifier bits" (these are used to ensure that GUIDs generated at nearly exactly the same time on the same machine are unique)
- An identifier for the algorithm (so that GUIDs generated with a different algorithm are unique)
This is however only 1 particular algorithm used for generating GUIDs (although I believe its the one used by the .Net framework)