Guids as primary keys

[symbiogenesis]

So I was using Guids as primary keys via EF 3.1 backed by Azure SQL Server and SQLite in a Xamarin.Forms app that was deployed on UWP, iOS, and Android.

This was causing some unique constraint collisions when doing syncing with DMS

I was able to solve this by ripping out all of the Guid primary and foreign keys, and switching them to ULIDs and storing them as byte arrays via a ValueConverter. There are at least 3 implementations of ULID for .NET. I haven't seen any problems since.

I am forced to use .NET Standard 2.0 because that is all that UWP supports.

I don't know if more recent .NET versions handle Guids better, and of course Mono is involved on the mobile platforms.

But it might be worth cautioning against Guids as primary keys.

[Mimetis]

Wow.
Guid is unique by définition.
First time I see someone with this kind of collision issue, to be honest

[symbiogenesis]

There's a lot of pieces to the stack, and I'm not really sure which part could be causing it. .NET, Mono, EF, SQL, SQLite, and DMS could each have been involved, and a lot of websites say that Guids can be produced differently.

I was also using this library, at the time, to allow sequential Guids. https://github.com/richardtallent/RT.Comb but ULID makes that irrelevant.

I'm honestly not sure why any of this happened, but ULID seems to just work. And I feel much better about my data syncing.

[Mimetis]

According to the documentation about SEQUENTIALID, they are not unique across machines:

Each GUID generated by using NEWSEQUENTIALID is unique on that computer.
GUIDs generated by using NEWSEQUENTIALID are unique across multiple computers only if the source computer has a network card.

RT.Comb seems to be a sequential GUID generated tool. I guess it suffers the same limitations