2 ms·
I don't understand putting type names into DB row IDs. You're safest using whatever IDs in your DB make it happiest (usually bigserial in Postgres), and the nee
by hot_gril 3y ago
I don't understand putting type names into DB row IDs. You're safest using whatever IDs in your DB make it happiest (usually bigserial in Postgres), and the needs might be pretty specific. Whenever you want to log row IDs, you add whatever context is needed, which will probably include things besides the ID either way. When you want to share an identifier with a customer, you use something entirely different.
The UUIDv7 properties are interesting, but it's worth noting that at least one DBMS really doesn't like the K-sortable property: https://cloud.google.com/spanner/docs/schema-design#uuid_primary_key https://cloud.google.com/spanner/docs/schema-design#uuid_pri...
- deleted 3y ago[deleted]
- quelltext 3y agoJust think about logging polymorphic object IDs. If you see an identifier with a type you can immediately know what table it is in and you can even build super simple tools like browser extension that let you look up objects by IDs as is. You can also just share these IDs as is with folks on Slack to debug etc. and they know exactly what kind of entities you are talking about. Super useful and I honestly don't wanna go back to a project that doesn't use this pattern.
- hot_gril 3y agoThose debug IDs (or URLs, etc) are worth having for the reasons you describe, but it doesn't mean you use those as primary keys in the DB. Something only needs to print them, and debug tools need to understand them.