You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Since the value of the underlying Guid is never exposed, we could consider using a Random Number Generator to generate the Id value. This would also have the benefit of being stronger cryptographically and more random though may influence performance negatively.
The text was updated successfully, but these errors were encountered:
The reason Guid was used in the first place, is that the original code was just a Base32 encoding/decoding of existing Guid in storage/memory. After introducing a separate data type, I don't see a need to rely on Guid anymore.
I'm not sure 100% random is the best trade-off, though. What about index fragmentation (sequential guids?) or sortability (ULID?). Once you've freed yourself from the shackles of UUIDv4, I think you need to consider these trade-offs.
Since the value of the underlying
Guid
is never exposed, we could consider using a Random Number Generator to generate the Id value. This would also have the benefit of being stronger cryptographically and more random though may influence performance negatively.The text was updated successfully, but these errors were encountered: