Re: Database schema for univesal usage

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

I can only refer this discussion back to DEC Rdb/VMS (Oracle/Rdb since 1994).

In DEC Rdb, you don't have to shut the database down to execute ALTER TABLE ADD COLUMN.
It's done in the context of a transaction. It get's a little messy if there's a concurrent transaction using the same table, so the system will force a quiet point. But the disruption to users is nowhere near what you describe.

If you want, you can extract a create script from an existing database, so you can always generate a new empty database on the fly. I think it's better to do maintenance on an existing create script, because you can add comments.

Create scripts for Rdb/VMS define columns in terms of domains. The product has been doing this since 1986, when the SQL term "DOMAIN" replaced the older RDO term "global field". Domains, in turn, can be defined in terms of Rdb primitives, or referred back to an external data dictionary. (We all keep a data dicionary up to date, don't we?)

And so on.

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. Received on Sat May 28 2005 - 13:26:21 CEST