11–20 of 337 posts
Otherwise: use FK's to maintain stronger data integrity.
As hesk mentions below, in Postgres, you can do all kinds of table ALTERing if needs be.
How would a Rails app be impacted by this? How would you create one-to-many, or many-to-many relationships? I'm sorry if this question sounds silly, but I've never heard this line of reasoning before and I'm fascinated by it.
I think you may be missing the distinction between the database feature "foreign keys", and the general concept of an entry that refers to another entry. Rails does the latter, but not the former, unless you explicitly do it yourself.
(Maybe Rails has changed dramatically in the last few years, but up until at least Rails 4, this was the case)
1: Obviously it's also way more, but the main codebase is a Rails app, and has been forever. This thread is from 2016, so that was probably even more true then than now.
The main criticism seems to be that the FK relationship makes migrating the referenced table difficult. But why not remove the FK with ALTER TABLE before the migration, migrate, and add the FK back again (which will catch any missing primary keys), preferably inside a transaction?
>preferably inside a transaction? MySQL does not support transactional DDL, unfortunately.
How would a Rails app be impacted by this? How would you create one-to-many, or many-to-many relationships? I'm sorry if this question sounds silly, but I've never heard this line of reasoning before and I'm fascinated by it.
The main criticism seems to be that the FK relationship makes migrating the referenced table difficult. But why not remove the FK with ALTER TABLE before the migration, migrate, and add the FK back again (which will catch any missing primary keys), preferably inside a transaction?
>preferably inside a transaction? MySQL does not support transactional DDL, unfortunately.
How would a Rails app be impacted by this? How would you create one-to-many, or many-to-many relationships? I'm sorry if this question sounds silly, but I've never heard this line of reasoning before and I'm fascinated by it.
How would a Rails app be impacted by this? How would you create one-to-many, or many-to-many relationships? I'm sorry if this question sounds silly, but I've never heard this line of reasoning before and I'm fascinated by it.
When posts like these come up, I'd like to remind people that context matters when making technical decisions. What works for large companies with huge scale (GitHub, Google, Facebook) may not work for you. As a counter point to the linked issue, I operate a few small applications. Foreign-keys (and constraints in general) are great at ensuring that invalid data doesn't find its way into your database. Yes, they have…
The reply in the GitHub thread we’re talking about makes it clear that they still perform FK validation - it’s just performed in the application code rather than the DBMS.
I note there is another alternative: deferred constraints - or just run a query to check for invalid rows at 3am every morning.