4 ms·
This is not remotely true. You can do this with pretty much any database that supports SERIALIZABLE isolation-level transactions correctly. The point is that a
by Diggsey 7y ago
This is not remotely true. You can do this with pretty much any database that supports SERIALIZABLE isolation-level transactions correctly.
The point is that application code has bugs, and it's a lot easier to specify your constraints declaratively in a single place using a purpose-built DSL (SQL) than it is to enforce them procedurally every time you access the database.
- lmm 7y agoI'd argue that any decent application programming language can express these constraints better than SQL can.
- spookthesunset 7y agoHow? FK constraints are trivially expressed in SQL. It is just a "REFERENCES table_blah ON DELETE DO BLAH ON UPDATE DO BLAH".
- zzzeek 7y agoif you are avoiding the use of foreign keys for the high and lofty goal of "performance" and 100% uptime while you run your fancy online migration utilities, SERIALIZABLE isolation is the last thing you would be using as it does what it says, serialiazes transactions and locks things like crazy. lots of waiting on locks, lots of deadlock potential. Throw in InnoDB's quirky implementations of isolation levels and you'd be in for a world of fun.