Welcome to Kurt Lidl's Database Musings Page


This page has some information about database issues, thoughts about relational databases and open source software and a little bit of information about issues underlying database systems.

Notes about ACID (taken from http://slashdot.org)

Authored by yet another ``Anonymous Coward''

Since I saw that many people are talking about transactions, I wanted to give a short view of what actually a transactions. People who are really interested should refer to the before mentioned book of Gray/Reuter "Transaction Processing" or even the original paper by Härder/Reuter (1981) which introduced ACID transactions. Since when you're into computer science and databases and are talking about transactions you probably mean ACID transactions.

ACID stands for:

ATOMICITY: transactions either succeed (commit) or fail completely

CONSISTENCY: a transaction transforms the DB from one consistent state into another (since transactions are atomic, the DB is logically always in a consistent state)

ISOLATION: transactions are processed without the context of other transactions (logical one user system). Thus they are not interfering with each other

DURABILITY: changes caused by transactions are durable (that's where recovery, logging and so on comes in)

In order to ensure those properties a lot of research has been done and one can say that all basic things have been implemented. The hard part is of course efficiently implementing it, e.g. using B-Trees (or the new UB-Tree) for accessing and storing data efficiently. Logging and recovery mechanisms for ensuring durability. Locking mechanisms for isolation and also atomicity..... A database system actually offers almost the same depth as an OS, since it needs physical storage management, indexing, caching, query processing & optimization, parallel processing, distributed physical storage, distributed query processing, logging, fail safeness... So you might imagine that implementing a good DBMS is probably the work of hundred of work hours. An effort which is almost comparable with creating Linux itself...


Jeff Evarts writes:
I would like to nominate the quote:
``So you might imagine that implementing a good DBMS is probably the work of hundred of work hours''
for the understatement of the year award. Perhaps it's all in your definition of ``good''. The following estimates could provide a reasonable baseline of effort for the magnitude of the ``good'' that one wanted to achieve:
IF (Good == "can parse SQL-92 and give correct results")
THEN scheduled_engineering_hours = 1000;

ELSE IF (Good == "would qualify engineering-wise for TPC
         benchmarks and could have a score greater than 0.1%
         of the best result, but not yet have support tools")
THEN scheduled_engineering_hours = 10000;

This page has been accessed (counter) times since this counter was last reset (July, 2000).

Valid HTML 4.01! Kurt J. Lidl
lidl at pix dot net
Last Updated: $Date: 2007/12/07 03:22:02 $