Re: More on lists and sets

David Cressey wrote:
> "Jan Hidders" <hidders_at_gmail.com> wrote in message
> news:1143220066.912611.90060_at_i40g2000cwc.googlegroups.com...
> >
> > [...] 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.

I'm not so sure about Chris Date. His theory on temporal databases seems to be based on it, and in proposals such as in TTM he puts much effort in defining them.

As to how well we understand nested relations I tend to agree with you. Conceptually they are no problem at all, their theory is well established, even in the areas of concurrency management and integrity control. But in the area of query optimization I have the impression (from what I know of the literature) our grip on them is still a bit shaky. And this matters.

> 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.

How is that different from a a nested-relation flat-relation wrapper? Or did you want to store a larger class of trees? (Nested relations are a very restricted kind of tree.)

> However, I'm NOT in favor of discarding the RDM or normalization, with
> regard to database design.

I understand, but that is not what I wanted to suggest. That is why the words "as far as the programmer is concerned" where included in my question.

> I've written about that extensively in previous threads.

Ok. Apologies if I'm asking for things you already explained elsewhere.

• Jan Hidders