Re: More on lists and sets

From: David Cressey <dcressey_at_verizon.net>
Date: Fri, 24 Mar 2006 17:21:02 GMT
Message-ID: <2UVUf.11$ZJ.1_at_trndny04>


"Jan Hidders" <hidders_at_gmail.com> wrote in message news:1143220066.912611.90060_at_i40g2000cwc.googlegroups.com...
>
> David Cressey wrote:
> >
> > My definitions:
> >
> > programming language = the language the client uses to manipulate data.
> > query language = the language the client uses to retrieve data from the
> > database.
> > data sublanguage = the query language, an analogous update language (to
> > provide new data for the database), and the format for the data
conveyed
> > between the client and the server.
> >
> > Note that "data sublanguage" does not incorporate what's commonly called
the
> > DDL.
> > These definitions are not authoritative, but I'll use them, until I'm
> > persuaded otherwise.
>
> Within the context of our conversation *we* are all the authority that
> is required. :-) I'm a bit amazed by the opiinion that in this
> newsgroup we need authoratitive definitions to have more meaningful
> conversations, whereas often the real problem is that the will to have
> a meaningful conversation is missing. But I digress.

I didn't intend to imply that we did need authoritative definitions. I was just trying to preempt the respnses that would have asked me to state the authority for my definition. You and I are on the same page on this.

>
> > I might like something like
> >
> > for (select ... order by ...) do {compound step}
> >
> > among other things. But this is what I'm thinking about now.
>
> Ok. So direct embedding of queries in the programming language, but so
> that they are recognizable as such (either by syntax or some special
> marking), and the result is simply passed as the result of the
> subexpression. And I assume that it is up to the compiler to decide
> whether the result should be immediately materialized or traversed by a
> cursor or lazily evaluated, or whatever?
>
> > One thing I want from the insert is to pass a tree of records,
containing
> > multiple record types, to the transformer in a single operation, and
have
> > the transformer traverse the tree and generate multiple inserts into
> > multiple tables as needed. Thus I can pass a tree representing an
"invoice"
> > as a single item. The invoice will have a repeating group in it, the
> > "invoice detail", and I shouldn't have to worry about that.
> >
> > In other words, the programmer doesn't normalize the data. The
transformer
> > does.
>
> Just to be clear, by "normalizing" you mean flattening, right? (So
> you're using Dawn's definiton of normalization. :-) ) So would it be
> fair to say that conceptually, as far as the programmer is concerned,
> the database stores nested relations? So, your transformer is actually
> a nested-relation flat-relation wrapper.
>

Not quite.

First off, I'm not sure I fully understand the consequences of permitting nested relations in a relational database. I'm in favor of designing tables with simple domains. Neither Date nor Codd give this issue the importance that religious devotees do.

But I digress.

Conceptually as far as (some of ) the programmers are concerned, the database stores trees. The concept of relation is unnecessary for (some) programmers. In other words, I'm interested in an outer shell, that's beyond the relational interface, that makes people who prefer trees to relations feel at home.

However, I'm NOT in favor of discarding the RDM or normalization, with regard to database design.
And, I'm in favor of designing databases that materialize some joins, for specific purposes, even when normalization theory would dictate not materializing those joins.

I've written about that extensively in previous threads. Received on Fri Mar 24 2006 - 18:21:02 CET

Original text of this message