Guid.NewGuid().GetHashCode() for DB

Question

Would this be reliable for using as an ID for data storage(SQL Server)?

I would use a guid but I prefer a numeric value.

Answer 1

A guid is more likely to represent a record uniquely than a numeric value.

Along with:

• GUIDs ensure global uniqueness
• GUIDs can be moved across databases nicely
• GUIDs reduce the number of joins required

---

See this : Guid Or Int Primary Key?

Answer 2

Would this be reliable for using as an ID for data storage(SQL Server)?

No. GUIDs are 128-bit but hashcodes are 32-bit. Therefore, there are necessarily collisions. It may be unlikely that you ever encounter one, but you are not guaranteed to never encounter one.

What you want for reliability is a guarantee that you never encounter a collision. If you insist on using Guid.NewGuid().GetHashCode() then you need to add logic to detect collisions. GUIDs do have advantages (and disadvantages) but without additional information I would suggest using an auto-incrementing int column. Especially as you say you want a numeric column I would lean towards using an IDENTITY.

Answer 3

A real GUID is designed to be unique. When you reduce that to an int (via GetHashCode) the probability of it being unique is reduced.

There is one good reason to use GUIDs (uniqueness) and this code removes that GUID feature.

Answer 4

If you want a numeric value then use an IDENTITY column. If you want a GUID, then use a uniqueidentifier. Simple as that.

Don't try to mix and match. Don't hash a GUID to get a numeric value. That will leave you with all of the disadvantages of a GUID column (larger data/indexes, page splits) while stimying most of the advantages (actual uniqueness, replication support). In addition you get none of the advantages that a sequential numeric ID would give you, such as temporal ordering and index performance.

Answer 5

I'd say just use a GUID as the value on the column. Then no issues.