Re: More on lists and sets

"Jan Hidders" <hidders_at_gmail.com> wrote in message news:1143192770.608043.12120_at_i39g2000cwa.googlegroups.com...
>
> David Cressey wrote:
> >
> > Isn't a "query language" and a "data sublanguage" essentially the same
> > thing?
>
> Not if you define these terms in the way I did: query language = the
> language that the client uses to retrieve data from the database
> server, data sublanguage = the language the client uses to manipulate
> data. So now I hope my definitions match yours. :-)
>

Our defenitions still don't match. I hope you don't mind if I spend some time on this, because I think it's worth it.

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.

> Of course, from a programmer's point of view there may not be a reason
> why these should be different, or even that is preferable if they are
> the same, but in general there are different design considerations
> here.
>

Here's what I speculate:

From the programmer's point of view: its desirable to have an integrated programming language that incorporates the functionality of the exchanges between the client and the server for providing and using database data.

From the source code reader's point of view: the syntax of the "data sublanguage" should not make reading source code any harder than it already is.

From a compiler writer's point of view: it's desirable to have the compiler be able to express the "data sublanguage", or some binary equivalent of it, as generated code, just like the machine code that the ordinary program functions generate, only for a different machine.

From the DBA's point of view, it's desirable that the data sublanguage not subvert the information principle, or the constraints that the DBA guarantees to the user community.

From the AI user's point of view, it's desirable to generate data sublanguage at run time, and have the necessary tools needed to compile it before execution.

If this sounds like hand waving, it's because it is.

> > [...] I want a
> > transformer that on one side looks like a query, and accepts a result
table
> > (set), and on the other side looks like a list that can be opened and
read
> > one element at a time.
> >
> > Going the other way, I want to be able to build a list, one element at a
> > time, and then shove the entire list into a transformer, and have the
list
> > contents inserted into one of more tables.
>
> I'm still not completely sure what that means. Would that be like
> wrapping all cursors in an Iterator object? And wrapping calls to
> inserts into objects that insert a list of tuples at once? Or do you
> want transparent integration in your programming language?
>

I'm really, really not sure yet.

I might like something like

        for (select ... order by ...) do {compound step}

among other things. But this is what I'm thinking about now.

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.

Why do I want normalized data in the database? All the regulars in this forum understand the answer to this question, even the ones who disagree. Received on Fri Mar 24 2006 - 15:25:04 CET