Re: how to build a database from scratch

From: paul c <toledobythesea_at_oohay.ac>
Date: Tue, 05 Dec 2006 14:43:35 GMT
Message-ID: <rAfdh.425555$5R2.249355@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.
> ...

This is reminiscent of the Codasyl pitch of the 1970's, eg., theory follows implementation. It's remarkable how thirty years later, so many people don't mention Codd's basic point - unless a DBMS first and foremost implements a formal theory, eg., one that prescribes a logical structure and data operators that preserve the structure, we are walking on quicksand.

p Received on Tue Dec 05 2006 - 08:43:35 CST