3 ms·
> Notice it says "... committed transactions are visible to all future transactions (consistent), ..." > This is not correct because the data can be overwritten
by cx01 17y ago
> Notice it says "... committed transactions are visible to all future transactions (consistent), ..."
> This is not correct because the data can be overwritten by a subsequent transaction.
It seems the paper is completely wrong here. AFAIK the C in ACID means that the integrity constraints in the database will always hold, i.e. no foreign key may reference a non-existing row. This would explain why they changed it in the later version of the paper.
Your reference to the Haerder, Reuter paper is interesting. It seems they kept the definition of consistency pretty vague.
- by 17y agoYes, that seems correct. The Wikipedia entry explained consistency best for me http://en.wikipedia.org/wiki/ACID#Consistency http://en.wikipedia.org/wiki/ACID#Consistency which is as you say with the keys for normal databases. It made clear for me the distinction between application level consistency, the bits that have to be enforced by the program, and database level consistency, which can vary depending on the sophistication of the database, and is enforced by the database. I hadn't really thought about that before. I suppose you could have a database that was less clever and left most of the consistency to the application but still be ACID compliant so long as you defined the scope of the database consistency carefully.