Re: how to build a database from scratch

paul c wrote:

> Science? Most of what I've seen is anecdotal theory at best. When the
> Gray, Reuter book came out many called it an "instant classic". What a
> disappointment, mostly haphazard addendums to various implementations.
> Think about it - what does a concurrency manager do except insert,
> delete and query a very specialized database? If a DBMS can't define
> its concurrency logic in terms of whatever its underlying application
> data theory is, I'd say it's missed the boat as far as having a theory
> of concurrency is concerned. Call me a fanatic!

There is 'science' to the extent that the physical implementation of transaction processing systems has long been a subject of empirical study. There is no over-arching mathematical treatment of the subject, except a scattered few bits and pieces of graph theory and some queueing. Mostly we study transactions processing as an engineering discipline - applications of data structures and algorithms to achieve a fairly tightly defined set of properties.

And look - I'm as fundamentalist as anyone about what logical properties a DBMS should support. I'm a little more radical than some in that I happen to think that relational approaches to computer programming are useful. I'm thoroughly convinced that a relational operating system is both practical and desirable, for example, though I think reasonable folk can disagree about what quality of service guarantees such a system might make and how you might work with such a beast.

But DBMSs do "define its concurrency logic in terms of whatever its underlying application data theory is." It's just that the "underlying application data theory" here is a procedural language and the physical layer of chips and disks and what-not. We're talking about how to build such a system 'from scratch'. Received on Fri Dec 08 2006 - 20:37:57 CET