4 ms·
My vote is for ids with prefixes. If you've ever used the Stripe API, you know how nice it is that all customer ids are prefixed with `cus_`, all product ids ar
by robbie-c 4y ago
My vote is for ids with prefixes. If you've ever used the Stripe API, you know how nice it is that all customer ids are prefixed with `cus_`, all product ids are prefixed with `price_` etc. I want that in postgres, so that any time you see an id you know exactly what kind of entity you are dealing with. It'd be incredibly useful for dealing with data analysts, and also for debugging production issues from logs / crash dumps.
You wouldn't need to store the prefixes at all, it'd be part of the column metadata, but it would be prefixed before sending the data back to the client.
I could do this at the ORM level but in my experience even with the greatest ORM in the world you often have to drop into raw SQL. Additionally people might have multiple ways of accessing the same db or a read-only duplicate.
- jrockway 4y agoYou can do this with numbers. Customers start with 1, products start with 2, etc. This is a little annoying if you aim small (products are 200-299, but now you have your 101st product), or design this scheme without realizing you need to add a 10th entity (or 100th), but it does mostly work.
- anttihaapala 4y agoI've wanted this too. Postgres allows one to write custom data types in C or other system programming language. The only limitation is that the "type modifier", in this case the prefix, would need to fit in a "single non-negative integer", so in priciple using e.g. 5 bits per character you could get up to 6 lowercase letters, `-`, `_` etc into the prefix. Of course a custom extension would have limited utility if it doesn't land into cloud services like AWS RDS.
- mixmastamyk 4y agoI worked on a db that did this once. Prevented generic code being written that could work over multiple objects/tables. Caused more work than it prevented bugs.