Re: Database schema for univesal usage

From: David Cressey <david.cressey_at_earthlink.net>
Date: Mon, 30 May 2005 13:36:14 GMT
Message-ID: <iFEme.10613$M36.1370_at_newsread1.news.atl.earthlink.net>


"Kenneth Downs" <knode.wants.this_at_see.sigblock> wrote in message news:phfrm2-ihr.ln1_at_pluto.downsfam.net...

> Hmmm, I'm thinking real world situations here. Emails and word processing
> documents are used by the people making the decision. The decision to
> alter the database (for any of the reasons listed above) is made, and work
> begins.

The real world has changed several times since my heyday, and not always for the better.

In my heyday, the database reflected not the data architecture of a single application, but the confluence of the data architectures of several applications, possibly written and supported by different ogranizations.

The only one who really knew what was going on was the DBA. The DBA had to be both at the top his technical game, in order to keep the datbase out of trouble. But the DBA also had to regularly attend content oriented business meetings, in order to keep the data in the database out of trouble.

Since that time, the DBA function has gravitated towards the technical end, like that of system manager or network administrator. It's not clear to me who has inherited the job of integrating enterprise data.

The data dictionary for DEC Rdb had this attrobute called "COMMENT". If you wanted to, you could comment
every lexical item, right in the database. The way it was stored created minimal impact for people and processes that were uninterested in the comments.

> Now back to the real world. After years of this activity, where the
system
> has been changed numerous times for every reason listed above, the
> company's decision process gradually becomes governed by fear. They fear
> to change anything because nobody really know's whats going on anymore.
[1]
>

See my comments above, concerning the DBA. If nobody really knows, then I'm going to characterize the database contents as "out of control". I don't really mean to be snide about this, but I think control is a vital aspect of good management.

> But anyway, the structure documentation issue sounds like an echo of
> ever-mournful database-code coupling lament. It drives me ever more to
> believe that an authoritative and _functional_ specification must exist
> outside both the database and the code that governs both. It must be
> functional, that is, integral to the workings of the system and offering
> benefits to use, otherwise maintaining it would be a chore and so it would
> never happen.
>

Sounds a little like the Dec Data Dictionary to me, but maybe I'm missing part of your point.

> FOOTNOTE:
>
> [1] There is a great Star Trek episode where this is illustrated, Scotty
has
> been hypnotized so that his worst fears are governing him, and it causes
> him to be unable to steer the ship, instead of knowing what to do, he says
> to Kirk, with this great intense Scotty look, "Captain Kirk, these are
> sensitive instruments! If you upset their delicate balance, we'll all be
> lost, forever lost!"

Isn't this the episode where Jack the Ripper invades the ship, and feasts on fear? Received on Mon May 30 2005 - 15:36:14 CEST

Original text of this message