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

"Kenneth Downs" <ken_remove_underscores_downs_at_downsfam.net> wrote in message news:58s0bb.ge4.ln_at_mercury.downsfam.net...
> Quoting unnamed sources, Marshall Spight claimed:
>
> Marshall: This may be a duplicate post, I had the date screwed up on my
box
> and cannot see the first try.
>
> > "Kenneth Downs" <ken_remove_underscores_downs_at_downsfam.net> wrote in
> > message news:0gvrab.dhl.ln_at_mercury.downsfam.net...
> >> 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
>
>
> The idea is that you do not want a schema to capture the syntax of
> SQL itself.

Well, of course not syntax and not SQL. One wants it to capture the semantics of a fully relational language.

> Rather, you first need a very detailed system catalog (as Mr.
> Badour immediately surmised), and then the operations you perform tend to
> fall into a few categories, such as imports, exports, warehouse
generation,
> and data procesing.

Imports are assignments and exports are queries. Assignments and queries, I get. Warehouse generation should be totally unecessary. If not assignments and queries, what do you mean by data processing?

> Here is a single example of the type of code we generate when we have a
> strong system catalog. Any mature app in the field is going to have an
> import or three, or six hundred, so how do you handle that? Do you write
a
> lot of very specific routines in a host language and/or SQL? Much better
> to create an IMPORT handler that expects parameters that are Scalar
> Complete.

What's wrong with: dbVar1 := dbVar2 ? Or dbVar1 := dbVar1 UNION dbVar 2 ?

> We ask, what is the bare minimum number of parameters I need to
> give an IMPORT engine so that it will import a table?

Why restrict things to a single table? Why not a set of tables or even an entire database?

> -> Like column names are copied straight over
> -> Where appropriate, similar columns can be padded out
> -> A map of columns can be provided when you need to specify
> things that are not safe for defaults, such as trimming
> values and so forth.

What was wrong with the relational algebra or with the relational calculus that you rejected both of those? They both strike me as much more powerful than the simplistic transformations you mention above.

> Armed with these assumptions

... to make your life as implementer easier. There is no theory behind any of this. The theory has already proposed much better solutions.

> INSERT INTO Errors_list
> SELECT T1_inbox_Key,"Derived_error_Literal"
> FROM t1_inbox
> where reference_column not in (Select key_column from ref_table)
>
> You can then code in parameters that do the opposite, such as what we call
a
> "force true" by populating the reference table:
>
> INSERT INTO Reference_table
> SELECT Reference_column FROM t1_inbox
> where reference_column NOT IN (Select key_column from ref_table)

What good is referential integrity if you turn around and generate nonsense data to force corrupted data into the database? Received on Thu May 29 2003 - 01:17:57 CEST