Join GitHub today
GitHub is home to over 36 million developers working together to host and review code, manage projects, and build software together.Sign up
Thoughts on Foreign Keys? #331
Thanks for your hard work on
As I familiarize myself with the way it all works, I noted that foreign keys are explicitly not supported, but that they may be to some extent in the future.
Looking through issues in the repo, I also noted this expected feature that the table has neither foreign keys pointing to other tables, nor foreign keys pointing to it.
Could you please expand on your thoughs about foreign keys, and what you mean by “some extent” for their potential support? I am also curious: does this limitation mean that you don’t use foreign keys at all in GitHub’s MySQL databases, or do you use them and manage those tables somehow differently?
Thanks for your time and consideration!
At GitHub we do not use foreign keys, ever, anywhere.
Personally, it took me quite a few years to make up my mind about whether foreign keys are good or evil, and for the past 3 years I'm in the unchanging strong opinion that foreign keys should not be used. Main reasons are:
This last bullet is not a chicken and an egg, as you might think. FKs impose a lot of constraints on what's possible and what's not possible.
Here's an old post of mine, reviewing the first appearance of Facebook's OSC, and which includes some thoughts on foreign keys: http://code.openark.org/blog/mysql/mk-schema-change-check-out-ideas-from-oak-online-alter-table
Let's say you have two tables, P & C, standing for Parent & Child, respectively. There's a foreign key in C such that each row in C points to some "parent" value in P.
Doing schema migration of C is possible. However since foreign keys have unique names, the new (migrated) C table will have a FK with a different name than the original one.
Doing schema migration of P is just not going to work. Recall that
There's more discussion on the documentation of pt-online-schema-change