Re: Interesting papers

From: Mikito Harakiri <mikharakiri_nospaum_at_yahoo.com>
Date: 18 Jun 2004 14:14:05 -0700
Message-ID: <8a529bb.0406181314.493b6c36_at_posting.google.com>


hungrylion2002_at_yahoo.ca (HungryLion) wrote in message news:<df89bd03.0406121852.2dca8e0e_at_posting.google.com>...
> "Mikito Harakiri" <mikharakiri_at_iahu.com> wrote in message news:<r%ryc.27$8T6.276_at_news.oracle.com>...
> >>
> > How about
> >
> > http://ece.ut.ac.ir/classpages/AdvancedDataBaseSystem/Paper/DB_Paper/P001.pd
> > f
> >
> > ?
>
> Yawn. A paper from 4-5 years ago about how components would save the
> free world from the universal database monolith and the dba rocket
> scientist they conjured up in their active imaginations. Well they
> gave it a new name RISC building blocks or something. Its kind of
> funny...they diss the word 'universal' from certain factions in data
> management as some silly idea of world conquering fascists while
> ironically pointing out the need for a "universal glue" for their
> components. This black magic is/was? supposed to be the motivation
> for Microsofts OLE DB gobbldygook.

The interesting part was how they interpreted manageability and ease of use. I totally agree: you can simplify the product if you throw away parasitic features (together with the code that supports them). If that kind code cleaning is not done, than the product becomes bloatware. And code refactoring can't be achieved without streamlining the interface language -- SQL. Removing redundancies, inconsitencies (eg. "not in" vs. "not exist"), and plain nonsence (eg. ANSII SQL standard join syntax).

"Manageability" perspective today, however, turns out to be more code that have to police the existing junk. More auxilairy structures, and some background processes taking the resources and becoming new sources of bugs. How is it more productive when DBA have to comprehend all this additional burden? Received on Fri Jun 18 2004 - 23:14:05 CEST

Original text of this message