How much can I rely on .Net GUIDs?

Question

How much can I rely on a GUID in .NET? My SA told me that

we will use the GUID as primary keys in all tables.

I am wondering about the reliability of a GUID as a primary key.

Could there be any chance of duplication?

Should we really use this method?

What about performance?

Any advice would be helpful to me.

Answer 1

These are a few points for a GUID that give you an answer.

Advantage:

• Unique server.

Inconvenience:

• String values ​​are not as optimal as integer values ​​for performance when used in joins, indexes, and conditions.
• Requires more storage space than INT.

You can read the full post after this: SQL SERVER - GUID vs INT - Your opinion

Answer 2

Yes, there may be a duplicate, but it will not. The GUID is 32 char long and each char can be 0-F (hexadecimal). This means that there are 16 ^ 32 possibilities.

So, if you generate 1,000,000 GUIDs every second for 10 years, the likelihood that you will create a duplicate is around 1/1079028307080601418897053.

In my opinion, a GUID is a very good candidate for a primary key, which you can generate if from anywhere without preliminary verification if it already exists in the database.

Answer 3

You can take a look at these articles:

http://www.codinghorror.com/blog/2007/03/primary-keys-ids-versus-guids.html
http://databases.aspfaq.com/database/what-should-i-choose-for-my-primary-key.html

Personally, I use integers unless I need the primary keys to be unique across multiple tables and databases. It’s easier for me to debug 87 than 2A734AE4-E0EF-4D77-9F84-51A8365AC5A0 .

Answer 4

Thanks to the birthday paradox (problem) , you have about 50% of the duplicate search if you create a 2 ^ 64 GUID ... are you happy? (This is because the completely random GUID is 128 bits long, so there are 2 ^ 128 different GUIDs. The birthday paradox tells us that if you have aproximatevely sqrt (2 ^ 128) GUIDs, you have a 50% chance of collision, I say a completely random GUID, because there is some standard type of GUID where some numbers are fixed, but .NET does not use these standards (read here http://en.wikipedia.org/wiki/Globally_unique_identifier )

I will add that if the problem is related to the "speed" of db, you should read the following:

Cluster index primary key GUID performance improvement

Answer 5

For the most part, you can assume that they will never be duplicated. If your identifier in the table is set as the primary key, then in any case, inserting a duplicate will be an error.

The advantage of using these identifiers in a web application is that users cannot just test URLS with other identifiers, so it would theoretically be more secure (although you should have a server check for permissions anyway)

Answer 6

Guides can be very unique statistically very highly and therefore are good candidates for primary keys if different systems generate identifiers and they all need to be combined.

Eg. Work offline and cancel change to central db.