4 ms·
sharded setup with a bit fast and loose foreign key management, so very good for performance but not a drop-in replacement if you rely on your foreign keys to b
by whizzter 1y ago
sharded setup with a bit fast and loose foreign key management, so very good for performance but not a drop-in replacement if you rely on your foreign keys to be constrained/checked by the database.
- sgarland 1y agoSo perfect for most web dev companies, then. “We handle FKs in the app for flexibility.” “And how many orphaned rows do you have?” “…”
- rcrowley 1y agoThe question isn't how many orphaned rows do you have, it's whether it matters. Databases are wonderful but they cannot maintain every invariant and they cannot express a whole application. They're one tool in the belt.
- sgarland 1y ago> cannot express a whole application Not with that attitude: https://docs.postgrest.org/en/v13/index.html https://docs.postgrest.org/en/v13/index.html Orphaned rows can very much matter for data privacy concerns, which is also where I most frequently see this approach failing.
- jashmatthews 1y agoMost companies can afford not to give a shit until they hit SOC2 or GDPR compliance and then suddenly orphaned data is a giant liability.