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

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

Answer 2

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 3

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 4

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 5

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 6

This is a common approach and I'll name one good reason right off hand for going this route. You can generate the GUID before you hit the DBso you could execute say an insert asynchronously and you would know ahead of time what the ID will be.

Make sure you're primary key's data type is a UNIQUEIDENTIFIER type and you're all set.

Answer 7

Dim bom As New Dictionary(Of Long, Boolean)

Sub pageload() Handles Me.Load
    For i = 0 To 500
        Dim act As New Action(AddressOf collisionfind)
        act.BeginInvoke(Nothing, Nothing)
    Next
End Sub

Sub collisionfind()
    For index = 1 To 50000000
        Dim INTGUID = Guid.NewGuid.GetHashCode / 2 * Guid.NewGuid.GetHashCode / 2
        bom.Add(INTGUID, Nothing)
    Next
End Sub

Well I guess after all it is almost as good.

No collisions :D.

50000000 Loops on 500 threads is quite heavy. It's good enough for me.