Would this be reliable for implementing being an ID for data storage(SQL Server)?

I'd make use of a guid however i should you prefer a number value.

A guid is more prone to represent an archive distinctively than the usual numeric value.

Together with:

  • GUIDs ensure global originality
  • GUIDs could be moved across databases nicely
  • GUIDs reduce the amount of joins needed

Check this out : Guid Or Int Primary Key?

A genuine GUID is made to be unique. Whenever you reduce that for an int (via GetHashCode) the prospect of it being unique is reduced.

There's one valid reason to make use of GUIDs (originality) which code removes that GUID feature.

Would this be reliable for implementing being an ID for data storage(SQL Server)?

No. GUIDs are 128-bit but hashcodes are 32-bit. Therefore, you will find always collisions. It might be unlikely that you simply ever encounter one, but you're not certain to never encounter one.

What you would like for reliability is really a guarantee that you simply never encounter an accident. Should you insist upon using Guid.NewGuid().GetHashCode() you will want to include logic to identify collisions. GUIDs will have advantages (and downsides) but without more information I recommend utilizing an auto-incrementing int column. Especially while you say you'll need a number column I'd lean towards utilizing an IDENTITY.

If you prefer a number value then make use of an IDENTITY column. If you prefer a GUID, then make use of a uniqueidentifier. Simple as that.

Create combine. Don't hash a GUID to obtain a number value. Which will make you with all the disadvantages of the GUID column (bigger data/indexes, page splits) while stimying the majority of the advantages (actual originality, replication support). Additionally you receive no advantages that the consecutive number ID gives you, for example temporal ordering and index performance.

I'd say only use a GUID because the value around the column. Then no issues.

This can be a common approach and I'll title one valid reason quickly hands for going this route. You will get the GUID before you decide to hit the DBso you can execute say an place asynchronously and also you knows in advance exactly what the ID is going to be.

Make certain you are primary key's data type is really a UNIQUEIDENTIFIER type and you are ready.

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 suppose in the end it's nearly as good.

No collisions :D.

50000000 Loops on 500 threads is very heavy. It is good enough for me personally.