On 25/04/12 19:02, Doug Hellmann wrote: > >From a MySQL prospective that is probably more of an argument to use > transactions, not foreign keys. > > Transactions and referential integrity are related, but not equivalent. > Without referential integrity it's quite easy to commit a transaction > that leaves the database in a logically inconsistent state (it sounds > like that's what was happening in the case described by the OP).
>From the way I read it the example given wasn't a referential integrity check but a delete across multiple tables. > Is there a technical reason to disable strict referential integrity > checking with MySQL? Technically it can make upgrades/downgrades harder, no engines other than InnoDB don't support them whereas many engines support transactions, MySQL doesn't actually support them (they are passed down to the InnoDB engine even at the parser layer). There are several other reasons (bugs and performance) why I don't like the MySQL implementation I won't go into here. Kind Regards -- Andrew Hutchings - LinuxJedi - http://www.linuxjedi.co.uk/ _______________________________________________ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
