Re: Database schema for univesal usage

David Cressey wrote:

>
> "Kenneth Downs" <knode.wants.this_at_see.sigblock> wrote in message
> news:599im2-jon.ln1_at_pluto.downsfam.net...

>> David  Cressey wrote:

>> The ALTER TABLE takes a moment, sure, especially if you are working
>> alone, don't have any programs making use of the column, and have no
>> users who tend to dislike bringing the system down for changes.
>>
>> And if you don't have to write down why you did it, or justify it to
>> anybody, it's much easier than if you do.  Who needs documentation, we
>> can all remember, right?

<snip>

>
> But all this sidesteps the real issue you raise. Why are you doing it,
> and
> how will anyone who needs to know understand what you've done? My answer
> to
> that is, it depends.
>
> If you are in an experimental environment, it's because you are monkeying
> around. No big deal. You can always generate and populate another
> database, if you need to.
>
> If you are in a production environment, it could be several cases.
>
> You may be altering a table to meet the needs of the next build of the
> application software. You may, in fact, be running a script that came
> with the release of the new build. In that case, the justification should
> be documented elsewhere.
>
> You may be creating a non standard version of a standard table. In that
> case, you need an idiot proof DBMS. That's not DEC Rdb. Using DEC Rdb,
> the DBA can protect the database from the users, and the users from each
> other. But the DBA can't protect the database from the DBA.
>
> You may be creating a non standard version of a non standard table, one
> that was added at the site. If adding a new table breaks the existing
> application software, then the application developers are idiots. If
> you've got a non standard table at your site, then you've got non
> standard
> application software that manipulates the data in it. You know what to
> do.
> And you know how to document it, right? And whether to document it,
> right?
>
> There's more, but this should be food for discussion right now.
>
> The point you raise is profound, and it deserves extended treatment.
> Oddly
> enough, it's related to the "redesign of the abstract machine" that
> mountain man is discussing in another thread.

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.

Now imagine the perfect progrmmer, who comments the new code and changes to existing code so well (including cross-referencing them with searchable keywords) that any person who comes after receives a complete and total understanding of it. But even if such a coder/commentor existed, what of the database structure? When we look at the database structure, what comments or descriptions tell us what is going on?

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]

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.

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!"

-- 
Kenneth Downs
Secure Data Software, Inc.
(Ken)nneth_at_(Sec)ure(Dat)a(.com)