ACID. Set of properties (atomicity, consistency, isolation, durability) of database transactions intended to guarantee validity even in the event of errors, power failures, etc.
According to Gray and Reuter, IMS supported ACID transactions as early as 1973 (although the term ACID came later).[3] Characteristics[edit] The characteristics of these four properties as defined by Reuter and Härder are as follows: Atomicity[edit] An example of an atomic transaction is a monetary transfer from bank account A to account B. Consistency[edit] Isolation[edit] Durability[edit] Examples[edit] The following examples further illustrate the ACID properties. CREATE TABLE acidtest (A INTEGER, B INTEGER, CHECK (A + B = 100)); Atomicity[edit] Atomicity is the guarantee that series of database operations in an atomic transaction will either all occur (a successful operation), or none will occur (an unsuccessful operation). Consistency failure[edit] Isolation failure[edit] Combined, there are four actions: Implementation[edit] CAP theorem. In theoretical computer science, the CAP theorem, also known as Brewer's theorem, states that it is impossible for a distributed computer system to simultaneously provide all three of the following guarantees:[1][2][3] In 2012 Brewer clarified some of his positions, including why the oft-used "two out of three" concept can be misleading or misapplied, and the different definition of consistency used in CAP relative to the one used in ACID.[4] History[edit] The proof of the CAP theorem by Gilbert and Lynch is a bit narrower than that which Brewer had in mind.
The theorem sets up a scenario in which a replicated service is presented with two conflicting requests arriving at distinct locations at a time when a link between them is failed. The obligation to provide availability despite partitioning failures leads the services to respond; at least one of these responses shall necessarily be inconsistent with what a service implementing a true one-copy replication semantic would have done.
NoSQL. "Structured storage" redirects here.
For the Microsoft technology also known as structured storage, see COM Structured Storage. A NoSQL (often interpreted as Not Only SQL[1][2]) database provides a mechanism for storage and retrieval of data that is modeled in means other than the tabular relations used in relational databases. Motivations for this approach include simplicity of design, horizontal scaling and finer control over availability. The data structure (e.g. key-value, graph, or document) differs from the RDBMS, and therefore some operations are faster in NoSQL and some in RDBMS.
There are differences though, and the particular suitability of a given NoSQL DB depends on the problem it must solve (e.g. does the solution use graph algorithms?). History[edit] There have been various approaches to classify NoSQL databases, each with different categories and subcategories. A more detailed classification is the following, by Stephen Yen:[9] Performance[edit] Examples[edit] Strozzi NoSQL (RDBMS) NoSQL, with development led by Carlo Strozzi, is the latest and perhaps the most active in a line of implementations of the stream-operator database design originally described by Evan Shaffer, Rod Manis, and Robert Jorgensen in a 1991 Unix Review article and an associated paper.
Other implementations include the Perl-based rdb, a commercial version by the original authors called /rdb, and Starbase, a version with added astronomical data operators by John Roll of Harvard and the Smithsonian Astrophysical Observatory. Because of its strengths in dealing with pipe data, most implementations are a mixture of awk and other programming languages, usually C or Perl.
The concept was originally described in a 1991 Unix Review article, and later expanded in a paper (see reference above), as well as in the book, "Unix Relational Database Management". The reasons for avoiding SQL are as follows: In contrast to other RDBMS, NoSQL has the full power of UNIX during application development and usage.