Re: More on lists and sets

From: Jan Hidders <hidders_at_gmail.com>
Date: 24 Mar 2006 09:07:46 -0800
Message-ID: <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 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.

Received on Fri Mar 24 2006 - 18:07:46 CET

Original text of this message