Consistency (database systems)
|This article relies largely or entirely upon a single source. (December 2008)|
As an ACID Guarantee
- The guarantee that any transactions started in the future necessarily see the effects of other transactions committed in the past
- The guarantee that database constraints are not violated, particularly once a transaction commits
- The guarantee that operations in transactions are performed accurately, correctly, and with validity, with respect to application semantics
As these various definitions are not mutually exclusive, it is possible to design a system that guarantees "consistency" in every sense of the word, as most relational database management systems in common use today arguably do.
As a CAP Trade-off
The CAP Theorem is based on three trade-offs, one of which is "atomic consistency" (shortened to "consistency" for the acronym), about which the authors note, "Discussing atomic consistency is somewhat diﬀerent than talking about an ACID database, as database consistency refers to transactions, while atomic consistency refers only to a property of a single request/response operation sequence. And it has a diﬀerent meaning than the Atomic in ACID, as it subsumes the database notions of both Atomic and Consistent."
- http://lpd.epfl.ch/sgilbert/pubs/BrewersConjecture-SigAct.pdf "Brewer’s Conjecture and the Feasibility of Consistent, Available, Partition-Tolerant Web Services"
- http://drkp.net/papers/txcache-osdi10.pdf "Transactional Consistency and Automatic Management in an Application Data Cache"
- http://www.minet.uni-jena.de/dbis/lehre/ws2005/dbs1/HaerderReuter83.pdf "Principles of Transaction-Oriented Database Recovery"
|This database-related article is a stub. You can help Wikipedia by expanding it.|