David Cressey schrieb:
> "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.
That may be, but when starting from scratch, one has to start somewhere.
And while ACID is important, before you can guarantee data integrity
you have to store the data first, in memory or wherever. So, IMHO
the data access comes first, then joins, then (with going multiuser)
locking, then everything else.
Lots of Greetings!
Volker
--
For email replies, please substitute the obvious.
Received on Tue Dec 05 2006 - 07:27:20 CST
