patternMinor
Can You Drop Consistency from ACID?
Viewed 0 times
canacidyoudropconsistencyfrom
Problem
In his book "An Introduction to Database Systems" C.J.Date wrote a chapter about the ACID principles called "Dropping ACID". In this chapter he calls Correctness(Consistency) "essentially meaningless" and the other principles at most "a desideratum".
This book is from 2004 and everywhere i go on the internet i see ACID principles as the guidline for RDBMS application programming. Does that mean that Date's ideas to ACID were not accepted? Or is ACID from a theoretical point of view not as mandatory as it seems when reading internet documentation about database programming?
I hope my question makse sense and is in the right forum.
This book is from 2004 and everywhere i go on the internet i see ACID principles as the guidline for RDBMS application programming. Does that mean that Date's ideas to ACID were not accepted? Or is ACID from a theoretical point of view not as mandatory as it seems when reading internet documentation about database programming?
I hope my question makse sense and is in the right forum.
Solution
Content of the book
The author analyzes the ACID concept from a very theoretical point of view.
The essential part might be the first sentence of the last paragraph of the chapter:
Overall, then, we conclude that the transaction concept is important
more from a pragmatic point of view than it is from a theoretical one.
Another important part is his introduction of the "multiple assignment" operator (p. 487), which he uses as a solution for some problems which are addressed by practical DBMS by supporting transactions. This operation does not seem to work in MySQL, Oracle nor MSSQL. (Make it possible to update several tables with one query.)
His statement is: If we had this multiple assignment operator, deferred checks of constraints are not needed and should be applied immediately and not at the end of a transaction. The latter one results in making the C of ACID useless, as the database is then always consistent (if the C stands for consistency) or it's correctness is unenforceable (if the C stands for correctness).
Concerning Isolation he claims that this should mean all transactions should have absolutely no knowledge of other transactions might be running. This is likely not doable. He further tells that most DBMS provide "isolation level" settings, that undermine this concept in it's base.
Durability he writes could only apply to the most outer transaction, if nested transactions are supported.
Atomicity according to him is only needed because there is need for transactions. If the multiple assignment operator is available as atomic, one would not need atomic transactions.
What to take away
This is a very fundamental discussion about the ACID concept. Without judging if his critics is correct or not, there is a living landscape of DBMS, which is based on transactions.
C.J. Date himself writes that "we now have a better understanding of some of the assumptions on which that research was based". This means it's one of the fundamental aspects, which one cannot change easily in living DBMS. Remove transactions and push in atomic multiple assignment operators and no enterprise will want to update it's architecture, because this is a lot of change.
Thus you have read a theoretical chapter proclaiming how one could improve the properties of DBMS conceptually, and which would erase some problems fundamentally. But only because something might be superior, it will not be used in practice immediately.
You have basically reached the border between someone with a mere theoretical point of view and the practical world, in which there is more than theory, but an existing world, which has to wrap around.
The author analyzes the ACID concept from a very theoretical point of view.
The essential part might be the first sentence of the last paragraph of the chapter:
Overall, then, we conclude that the transaction concept is important
more from a pragmatic point of view than it is from a theoretical one.
Another important part is his introduction of the "multiple assignment" operator (p. 487), which he uses as a solution for some problems which are addressed by practical DBMS by supporting transactions. This operation does not seem to work in MySQL, Oracle nor MSSQL. (Make it possible to update several tables with one query.)
His statement is: If we had this multiple assignment operator, deferred checks of constraints are not needed and should be applied immediately and not at the end of a transaction. The latter one results in making the C of ACID useless, as the database is then always consistent (if the C stands for consistency) or it's correctness is unenforceable (if the C stands for correctness).
Concerning Isolation he claims that this should mean all transactions should have absolutely no knowledge of other transactions might be running. This is likely not doable. He further tells that most DBMS provide "isolation level" settings, that undermine this concept in it's base.
Durability he writes could only apply to the most outer transaction, if nested transactions are supported.
Atomicity according to him is only needed because there is need for transactions. If the multiple assignment operator is available as atomic, one would not need atomic transactions.
What to take away
This is a very fundamental discussion about the ACID concept. Without judging if his critics is correct or not, there is a living landscape of DBMS, which is based on transactions.
C.J. Date himself writes that "we now have a better understanding of some of the assumptions on which that research was based". This means it's one of the fundamental aspects, which one cannot change easily in living DBMS. Remove transactions and push in atomic multiple assignment operators and no enterprise will want to update it's architecture, because this is a lot of change.
Thus you have read a theoretical chapter proclaiming how one could improve the properties of DBMS conceptually, and which would erase some problems fundamentally. But only because something might be superior, it will not be used in practice immediately.
You have basically reached the border between someone with a mere theoretical point of view and the practical world, in which there is more than theory, but an existing world, which has to wrap around.
Context
StackExchange Database Administrators Q#61628, answer score: 9
Revisions (0)
No revisions yet.