3 ms·
That's fine when one application is using the database. I work in the enterprise space, and we have at least 5 different applications all working with the same
by SamuelAdams 7y ago
That's fine when one application is using the database. I work in the enterprise space, and we have at least 5 different applications all working with the same database. Each of these applications has their own team. Expecting each team to handle constraint checking uniformly in their applications isn't always feasible, so we use foreign keys.
GitHub's approach might work fine for small, focused teams who have exclusive control over a product. However, that's not often the reality of most organizations.
- spookthesunset 7y ago> That's fine when one application is using the database. It's not even fine for a single application. Said application has bugs in it. Said application can (and will) crash in unexpected ways that leave the database in an invalid state. And if you think that "oh, that will never happen to me". You just haven't been around long enough. It will happen, every single time. Any system without foreign keys will have corrupt data in it. Said system will have user-visible issues as a result. Just like only the backend can truly validate user input from a webform, only the database can validate its input.
- Mahn 7y agoThere are ways to prevent invalid states in a database without foreign keys, for example enforcing "all or nothing" operations via transactions.
- Volundr 7y agoUntil a programmer forgets to wrap the new feature in a transaction, or just has a bug in their logic that breaks the integrity. Or a db admin working directly in the database breaks it. Or a schema migration. It's not impossible, sure, but it requires you and everyone working with the data two be very, very disciplined, and is only as effective as the weakest link.