RDBMS [[Describe how rdbms differs from other [dbms], and list a few examples.]] ---- This is not very scientific, but it's how I like to think of it. Basically a db is a set of related data, a typical db have lists of values (tables of rows), each value is a list values (table columns), sometime a value (a field) is it self a list of values (a record from another list, hence relational) Sql (THE standard rdbms language) is used to define the lists, the relations and to insert a retrieve values. A non-standard procedural language is used to define triggers and procedures, with is compensate for what Sql can't to and add more restrictions (control if you prefer) on the values in the db. Some of the cool programmers I met on the net, seems to think that rdbms is overrated, I have no clue why? But I intend to invetigate more on when it can be a bad idea to use a rdbms. Most rdbms(es) promises to be ACID compliant. ACID are or should be the proporties of any db transaction . (A Atomicity, a TXN is performed in its entirety or not at all) (C Consistency, a correct TXN takes the db from one consistant state to another) (I Isolation, until they become committed, updates by a TXN are not visible to other TXN) (D Durability, once committed changes must never be lost) I personally find that between A and I, C seems redundant. It would be nice if someone can justify what C adds exactly. Question: what is considered a transaction in a db and whatnot? Is data retrieval (Sql select statements) considered a db TXN. Sometimes it is said that rdbms is a db topologies, other topologies include (network and hierarchical) A not new variation of rdbms(es) is ORDBMS(es) or Object-relational db management systems. Also OO-dbms are talked about, of course after I realized inheritance is just a relation, I started to think that OO-dbms are irrelevant and I started to doubt the intentions/good will of OO-dbms enthusiasts (or sellers). Also the O in ordbms is nothing to get excited about! Try for yourself. ---- [NEM] Well, there is an awful lot that could be said about RDBMSs. Firstly, it is probably worth distinguishing between a relational [database], which is responsible for storing data as relations (sets of tuples, roughly), and a Relational DataBase Management System (RDBMS) which is responsible for managing access to such a database (e.g., takes care of concurrency issues, security, etc). The underlying relational model (see [Ratcl] for an extension that provides access to relational operators) is quite closely related to first-order predicate logic (FOPL), as a (mathematical) relation can be identified with a predicate (boolean valued function) which determines set membership of elements in the relation. If SQL had been more closely based on FOPL then perhaps we wouldn't need ad-hoc triggers/stored-procedures. Rule-based languages, such as [CLIPS] and others used in [Expert System]s are usually much nearer to logic (and much more powerful than SQL), as is [Prolog] (which is a great language for learning about relations). The connection to FOPL also partly explains why OO-relational mappings are sometimes a bit awkward: inheritance is a form of default reasoning ("all birds can fly", "a penguin is a bird, but it can't fly"), which is something of a tricky area in pure first-order logic, although there are several ways to do it (perhaps most explored in the area of semantic nets in AI). There is much more to say here, but very little of it has much direct connection to Tcl. Tcl does, however, have many extensions for dealing with all sorts of databases (check the [Category Database] links). ---- [Category Database] | [Category Acronym]