Add foreign keys to the Mysql-scheme

[tuxis-ie]

Also, add a .sql file that will create the foreign keys on existing databases. But only AFTER the 3.x_to_3.4.0-scripts are run.

[Habbie]

We need to make sure there are no performance/locking implications.

[tuxis-ie]

From what I see on a search on 'mysql foreign key performance implications', UPDATES/INSERTS (as I would expect) might suffer from a foreign key. For SELECTS, it looks like people are saying that foreign keys actually improve performance because of the indexes it needs.

Foreign keys AFAIK only kick in on updates and inserts, to check if the foreign key matches. For selects, the foreign key is ignored.

http://books.google.nl/books?id=IagfgRiKWd4C&lpg=PA282&ots=wZa7nYWtzh&dq=mysql%20foreign%20key%20performance%20implications&hl=nl&pg=PA281#v=onepage&q=mysql%20foreign%20key%20performance%20implications&f=false
http://dba.stackexchange.com/questions/15918/foreign-key-constraints-with-mysql-innodb

[Habbie]

I am happy to merge this right now if it is made optional. Alternatively I will entertain serious benchmark numbers :)

[tuxis-ie]

I'll happily benchmark stuff. Just let me know what you want benchmarked. :)

[Habbie]

Some things I care about in this context:

1. performance of a busy slave with tens of thousands of domains
2. chances of hitting long locks/deadlocks on such a slave because a lot more happens during a transfer now

[tuxis-ie]

PR Updated to only add a file which you can optionally use to enable foreign keys

[cmouse]

Would be nice if you could include the file in test suite, though.

[Habbie]

Not sure about that - would make the test suite deviate from common production setups

[cmouse]

On the other paw this does make the tests more stringent and does not enable anything new

[Habbie]

True. No objections. Please help @tuxis-ie out, he doesn't know where to put it!

[Habbie]

If you add some docs we can merge this, with or without tests.