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_at_pd7urf3no>
>
>
>
> 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.
> ...
Date: Tue, 05 Dec 2006 14:43:35 GMT
Message-ID: <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.
> ...
p Received on Tue Dec 05 2006 - 15:43:35 CET