re: databases boring? (Re: "Perl is the duct tape)

Paul Benninghoff (
Tue, 14 Jul 1998 15:02:34 -0700 (PDT)

Excuse the late arrival to this thread. Having been away from
civilization for a few weeks, you'd get no argument from me if you
said that all of CS is boring, and writing a full dbms ain't my idea
of fun either, but still...

> > > > [ Nelson Minar wrote: ]
> > > > It is curious, though, that free databases are less common than,
> > > > say, free web servers. I think it's because most hackers think
> > > > databases are kind of boring - who'd want to spend so much time
> > > > creating a database program?

> > [ Sundar Narasimhan wrote: ]
> > > Nah. The real reason is that not many universities teach about
> > > databases and "production computer science".
> Doug Lea wrote:
> > Nah. The real reason is that free software is put out by people who
> > love to code it. And practically nobody loves to code databases :-)

> [David McCusker wrote: ]
> I've never had even the slightest interest in either RDBMS's or SQL.
> They seem even more boring than address books. :-) A lot of common

Nah, the *real* real reason is that a dbms is roughly of equal
complexity to an OS, which is to say, a far more formidable
undertaking than developing, say, a web server. What might be
surprising is that there are such complex pieces of free open software
as freeBSD and Linux out there at all, except that your average,
run-of-the-mill hacker may want to use an OS for all kinds of things,
yet he probably doesn't have a couple of gigs of data burning a hole
in his pocket ;).

What you do get, then, in the way of free dbms's with source, are
systems from the more resource(slave)-rich educational institutions
that are meant (at least at first) to be educational and research
platforms. A good (late-breaking) example of a relatively
full-featured, general system, which I suspect is less mature (for the
moment) than PostgresSQL, is PREDATOR, which is an Object-Relational
system with roots in Wisconsin, but that is now based at Cornell:

As for what's boring or not, this is obviously a matter of taste
(background, biases, politics, inertia). I find much compiler work to
be dull as dishwater, (most) network protocols more boring still
(religious wars over competing RPC implementations? give me a break),
the endless debate over minor OO language features or what's an Object
or what's OO to be irrelevant and tiresome, and alot of what goes into
building an OS to be trivial detail (granted, it'll bury you if you're
not careful).

In contrast, IMHBO (Humble and *Biased* Opinion), the notions behind SQL
and relational databases are, for starters, far more mathematically
interesting and elegant than any of the above. (Indeed, when
introduced, they were dismissed by many as too mathematically
complex). They represent a manifestation (the most successful
manifestation) of the idea of a declarative specification language
with (importantly) nice algebraic properties that facilitate dynamic
adaptation. Some feel that this notion (with relational technology as
the reference point) can be extended beyond the traditional dbms
world, and can play an important role in bringing robustness and
adaptivity to next-gen systems.

I may be out of my depth here, but when I first encountered that
"revolutionary" idea from the OO community, open implementations (some
25 years after Codd's paper), it struck me that it fell short of what
relational technology had. OI espoused exposing multiple
implementations to the programmer, in a supposedly principled manner,
but those principles, such that they were, seemed dubious. What was
lacking was the mathematical underpinnings, the nice algebraic
properties that give rise to the real power of relational technology.
OI was trying to be more generic in the operations supported (though
also more static, less adaptive), but in the process it was throwing
out the baby with the bath water, in a sense. Much of the research
that has followed suffers over this issue, I believe. For example,
related work on adaptive OS that I'm familiar with seems to reduce to
a few adhoc operations that switch implementations based on a
hardwired guard on dynamic system state. It's unclear how much of
this work can be extended in any general way.

My speculation was (is) that a good question to ask is how far can we
go while retaining the baby, the algebraic properties that support
compositional adaptation, rather than chucking these and trying to
back into a principled approach. Commentary from the more OI-fluent
is encouraged, I may well be out to lunch.

Well, so, a strange segue into OI... Of course the ideas behind RDBs
are pushing 30 years old (I'm told ;), not exactly the flavor of the
month. In matters of taste, to each his own.