Re: Database Builders, Code Generators, On-Topic?

From: Marshall Spight <mspight_at_dnai.com>
Date: Mon, 26 May 2003 16:10:11 GMT
Message-ID: <D%qAa.741299$Zo.157027_at_sccrnsc03>


"Bob Badour" <bbadour_at_golden.net> wrote in message news:kqiAa.281$od6.72567878_at_mantis.golden.net...
> "Kenneth Downs" <ken_remove_underscores_downs_at_downsfam.net> wrote in message
> news:0gvrab.dhl.ln_at_mercury.downsfam.net...
> >
> > Our own tables are
> > outside of the system catalog.
>
> I suggest this indicates a deficiency in your system catalog.

I think you are misunderstanding each other here. (Which is easy when metadata is involved.) I think what Mr. Downs means is that his tables are in addition to the system catalog. Certainly if mention of his tables didn't *appear* in the system catalog, that would be a deficiency.

> > The third question could mean, "does it drop retired columns and tables?"
> > Mine does not, we just stop using them.
>
> I expect it to drop retired columns and tables. Otherwise, they simply take
> up storage and interfere with integrity. For instance, how does the updated
> schema deal with the fact that inserts no longer reference the retired
> column while at the same time it still exists in the schema?

Sometimes you want to drop retired columns and tables; sometimes you don't. An ideal solution would support both. Also, sometimes you want to move columns. For example, if you want less specificity of an attribute, it might move "in the direction of" a foreign key; if you want more, it might move in the opposite direction.

> Paul mentioned it to me in private correspondence. He sees a standard
> relational system catalog as a necessary step in elevating the relational
> algebra and the relational calculus to the database level. Instead of
> viewing a database as a set of relation variables, there may be advantages
> to viewing it as a single database variable with relation valued attributes.
> Interoperability would likely require a standardized system catalog, because
> it would be a component of any assignment statement of the form:
>
> dbVar1 := dbVar2

I definitely see advantages to a standard system catalog, and the problem doesn't seem all that hard to me. (But I don't see how db assignment particularly benefits from a standard catalog.) Just having DDL isn't a complete answer; you can't query the current state. It seems obvious to me that any DDL should just be syntax for operations on the catalog.

Marshall Received on Mon May 26 2003 - 18:10:11 CEST

Original text of this message