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
Thanks for all your work on cuid2. I'm considering using this library as a way to generate IDs in our Postgres DB, and I had a couple questions regarding recommendations for usage in cuid2:
I want to create stripe-like prefixed identifiers for my application (e.g. usr_ tz4a98xxat96iws9zmbrgj3a). Is this at as simple as concatenating the prefix with cuid ID or are there other considerations we must make?
Would you recommend using this as the primary key in our DB? I see a lot of discussion around using monotonically increasing IDs (ints/big ints) as primary keys for performance reasons and having a separate entity ID for usage in APIs. My concerns with the latter approach are a) you still need to either index on the entity id or maintain a look-up table mapping entity IDs to primary keys and b) your primary keys in a sharded DB are no longer unique.
Any advice or considerations would be greatly appreciated. Thanks!
The text was updated successfully, but these errors were encountered:
I'm no expert in any way but going with a simple concat. To me it's just adding a piece of non-entropic content and can't corrupt the benefits existing in the id. It leaks the type of data, which is the intent here anyway. I'd compare it to the 4 present to identify uuidv4 in a way.
There is quite a bit on this at in the README, does it help?
Hi,
Thanks for all your work on
cuid2
. I'm considering using this library as a way to generate IDs in our Postgres DB, and I had a couple questions regarding recommendations for usage incuid2
:I want to create stripe-like prefixed identifiers for my application (e.g.
usr_ tz4a98xxat96iws9zmbrgj3a
). Is this at as simple as concatenating the prefix withcuid
ID or are there other considerations we must make?Would you recommend using this as the primary key in our DB? I see a lot of discussion around using monotonically increasing IDs (ints/big ints) as primary keys for performance reasons and having a separate entity ID for usage in APIs. My concerns with the latter approach are a) you still need to either index on the entity id or maintain a look-up table mapping entity IDs to primary keys and b) your primary keys in a sharded DB are no longer unique.
Any advice or considerations would be greatly appreciated. Thanks!
The text was updated successfully, but these errors were encountered: