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

From: Marshall Spight <mspight_at_dnai.com>
Date: Mon, 26 May 2003 16:19:28 GMT
Message-ID: <k8rAa.989115$F1.120327_at_sccrnsc04>


"Kenneth Downs" <ken_remove_underscores_downs_at_downsfam.net> wrote in message news:0gvrab.dhl.ln_at_mercury.downsfam.net...
> Upgrades are actually the first reason I developed early versions of this
> system, when I was working independently 7-8 years ago. The flow is:
>
> 1. Our catalog equals "what I want"
> 2. The system catalog reveals "what is"
> 3. Generate a bunch of DDL to turn "what is" into "What I want"
> 4. Optionally Execute. Or stop and report the intended plan for
> review, approval, etc.
>
> This has the nifty added advantage that a first time installation is the
> same as an upgrade. If "what is" is empty, it builds the entire database.

This is extremely cool.

> Taken with the statement given below, "All operations that can be performed
> against a database can themselves be depicted within a database as scalar
> values", it is not so much a system catalog that we have as a business
> catalog.

Well, this is certainly true, because a string is a scalar, and all operations that can be performed against a database can be depicted as a string containing SQL. But...

I have been pondering lately this issue of representing database operations as relational data, and I'm beginning to believe that it's seductive but not all that useful.

Consider: if I want to model simple inserts into a table, then that beautifully manifests itself as a set of tuples that match the table heading. No problem. Now what if I want to model deletes? Uh, I suppose I could model that as a set of tuples to remove, but that's not that efficient. All I need is one key attribute to uniquely specify the tuples. So which key to use? Uh, I guess the "primary" one, eh? :-) Now what if I want to model updates? They come in so many flavors.

update table set a = 7 where primary_key =8

Now I need two columns: more than for delete, less than for insert.

update table set a = 7

How do I represent that?

update table set a = 7 where primary_key in (select b from different_table where c = 8)

What about that one?

Eventually it becomes clear that representations of updates need the full value of the relational calculus. (Which, stated that way, I guess should have been obvious.)

Marshall Received on Mon May 26 2003 - 18:19:28 CEST

Original text of this message