3 ms·
I once worked somewhere that used rails in lieu of foreign keys. The result was a brittle nightly delete_orphaned records script as well as obscure user visible
by norir 3y ago
I once worked somewhere that used rails in lieu of foreign keys. The result was a brittle nightly delete_orphaned records script as well as obscure user visible bugs. My team started adding foreign keys to our records and unsurprisingly caught bugs in our application code that otherwise would have been missed. Personally, I think the default should always be to usr foreign keys and only if you have a genuine scalability problem might you consider dropping them or put then in a different database with lighter data integrity guarantees.
- shayonj 3y agoI agree and makes sense. Starting out with them and then challenging the setup is a good practice. I like the idea of moving to a lighter data integrity setup too (ofc when possible)
- seadan83 3y agoThis anecdote is not very surprising to me. Foreign keys are on a scale of DB constraints. I opt to add a maximum of constraints where I can. Adding a date that should be in the future - I'm adding a constraint! Did you mess up your time zone conversions & are trying to add a date in the past - the constraint catches it. At some point the constraints are strong enough where with high confidence the following statement can be said: "if the data exists in the database at all, it is correct & complete." This is the "database as fortress" principle, that only correct data should ever be allowed into the database to begin with.
- enobrev 3y agoI worked on a couple projects in the early aughts like this (php / mysql). Even did it myself for a project and fortunately learned my lesson early enough to fix that very project and rely in the database to handle data integrity. Always important to remember that while learning from others is important; They're just as human as you are.