Re: how to build a database from scratch

From: David Cressey <dcressey_at_verizon.net>
Date: Tue, 05 Dec 2006 09:54:09 GMT
Message-ID: <5lbdh.1936$QD3.1772_at_trndny01>


"paul c" <toledobythesea_at_oohay.ac> wrote in message news:3G2dh.416432$1T2.182087_at_pd7urf2no...
> DBMS_Plumber wrote:
> > Joachim Pimiskern helpfully points us to:
> >
> >>http://en.wikipedia.org/wiki/B-tree
> >
> >
> > Attempting to build a DBMS-ready B-Tree implementation based on the
> > description in the Wikipedia entry will get you almost nowhere. While
> > the broad outline of the data structure and the operations seems to be
> > correct, a DBMS by definition a) provides transactional
> > quality-of-service guarantees, and b) supports multiple concurrent
> > users. These requirements complicate the implementation of the storage
> > management layer enormously.
> >
>
> Criteria a) and b) seem rather rigid to me at the same time as their
> lingo is open to interpretation, eg., whose particular definition?.
> Familiarity breeds contempt and calling those aspects the essence of a
> definition might just be a result of most products looking at things
> that way. From a purely minimalist point of view, I'd say the only
> essential is for a dbms to guarantee that it can pass from one
> consistent state to another given the operations it allows. Just what
> is a transaction is an application question AFAIAC. Concurrency is also
> very clearly an application issue, although a very friendly DBMS might
> offer builtin strategies. The trouble is that most offer stragegies
> that close some useful doors.

I couldn't disagree more strongly. A Database Management System (DBMS) offers, by definition, certain fundamental database management facilities. If it's lacking in these facilities, it's either defective or incomplete. I'm not sure exactly what criterion a refers to, but I'm taking it as providing ACID support for transactions. That's pretty fundamental for a DBMS.
Criterion b) is absolutely fundamental for the sharing of data among large numbers of users. And if you aren't sharing your data, then it's a stretch for you to call your container a database.

Note that none of the above is limited necessarily for relational DBMSes. You could have a DBMS that is not built on the relational data model, yet is a DBMS. All of the major DBMS products of the early 70s fit this description.

Likewise, you could have a relational system for storage and retrieval that is not necessarily a DBMS. But that's another discussion.

Concurrency (of update) is primarily a data issue, not an application issue. People whose focus is on the application, its logic, and its information requirements should not have to redevelop the entire science of managed concurrent update on their own. Witness Clipper in the 90s. Received on Tue Dec 05 2006 - 10:54:09 CET

Original text of this message