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

"Marshall Spight" <mspight_at_dnai.com> wrote in message news: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.

I understand what Mr. Downs is saying--I just do not think it is valid. He is inventing a system catalog as a system catalog should be. That tells me his current system catalog is deficient.

Discussing what is necessary in a system catalog so that it is not deficient is interesting and valuable in a database newsgroup.

Mr. Downs seems hung up on an arbitrary kludge he chose to make his life easier, and it appears he wants to put that kludge on some kind of a pedestal. I do not see how the kludge will improve things, and I can envision many ways it might harm things.

For instance, Mr. Downs' arbitrary restriction means that we cannot use regular expressions, and it means we cannot use a non-scalar relational expression domain.

Now, if Mr. Downs can justify the arbitrary kludge with more than just hand waving or if Mr. Downs can let go of the kludge, we might actually have an interesting discussion.

> > > 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.

If you don't want to drop retired columns, do not retire them. If you need to support multiple application views where some have the column and some do not, the column won't be retired. It might be partitioned into a different base relation appearing in some views and not others.

> An ideal solution would support both.

An ideal solution would transform the schema accurately, which means dropping retired columns. If you do not want them dropped, do not retire them.

> Also, sometimes
> you want to move columns.

Of course. There are any number of transformations to base relations and views that one might want to make. One might want to partition among rows using restrict just as one might want to partition among columns using project. One might also go in the opposite direction and combine base relations using join or union.

> > 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.)

The values of both dbVar1 and dbVar2 above have a system catalog component. The assignment above would replace dbVar1's system catalog with dbVar2's system catalog. For the assignment to work, the dbms must understand dbVar1's system catalog after the assignment. This poses no problem if both dbmses are running the same version of the same vendor's software, but could present problems in more heterogeneous situations. Unless, of course, there is a standard system 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.

I agree. I don't see how this justifies Mr. Downs' arbitrary restriction. Received on Mon May 26 2003 - 14:57:36 CDT