> 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.
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.
Comments
> 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.
Yes, that seems correct. The Wikipedia entry explained consistency best for me
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.