Re: how to build a database from scratch

"paul c" <toledobythesea_at_oohay.ac> wrote in message news:rAfdh.425555$5R2.249355_at_pd7urf3no...
> David Cressey wrote:
> > "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.
> > ...

>

Let's see if we can turn this into a reasonable discussion.

I'm certainly not about to suggest to the OP that he build a DBMS that is not relational as an exercise. And I didn't intend to imply any such thing by my earlier response. I also think that other responders should not suggest that he build a relational system that is not a DBMS. At least not if his goal is to build a DBMS.

The OP mentioned "building a database from scratch". The consensus of responders (including me) was that what he really meant was "building a DBMS". By way of analogy, he mentioned that he had built a toy compiler. I'm sure the toy compiler he built had a code generator in it, even if only a toy code generator.

Suggesting that someone build a DBMS without transaction managment and concurrency control makes about as much sense as suggesting that someone build a compiler without a code generator. And, as DBMS_Plumber has begun to explain, these are not features that you want to retrofit as an after-thought.

Plumber has lots more to say on this than I do, but if you've never studied the internals of any DBMS then you've got the opportunity to learn a lot from this discussion. Received on Wed Dec 06 2006 - 19:40:38 CET