Re: More on lists and sets


"Jan Hidders" <hidders@xxxxxxxxx> wrote in message
news:1143220066.912611.90060@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx

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.



.

Relevant Pages

  • Re: What does this NULL mean?
    ... are talking about catalogs and databases then the situation is the same. ... they can be viewed as one database. ... For example, in programming ... domain I need to describe my own programming language rather than do ...
    (comp.databases.theory)
  • Re: C#3 changes
    ... No doubt the coming MSSQLServer uses it in stored procedures. ... The goal seems to me that you use a single language for writing procs ... The database itself should provide all the type information. ... http://mindprod.com Again taking new Java programming contracts. ...
    (comp.lang.java.advocacy)
  • Re: Encapsulation vs separation of concerns
    ... One really doesn't want to rewrite entire applications when the ... > Did you really rewrite the application in the same language four times? ... > changes in programming languages are many. ... > programming languages have changed about every 5th year, while database ...
    (comp.object)
  • Re: Minsky still posting
    ... > I think this is another case of falling for the hype of Prolog rather ... Prolog is just another little programming ... > language, It isn't magic, it isn't intelligent, it is in fact rather ... If I want a database, I think of it as a thing with certain ...
    (comp.lang.prolog)
  • Re: How to make mulitlingual website?
    ... His design, while it works, makes the code very ... and scroll to "Consider Database De-normalization". ... It means if you have a bad language ... >| If you have several fields, normalization is even more important. ...
    (comp.lang.php)