Re: Reminder, blatant ad

"dawn" <dawnwolthuis_at_gmail.com> wrote in message news:1138382966.616817.236670_at_g47g2000cwa.googlegroups.com...
>
> JOG wrote:
> > Jan Hidders wrote:
> > [snip]
> > > > [...] Whenever I mention that I want to
> > > > work with such data structures as ordered lists with associated
insert
> > > > and delete functions, I am informed that I am talking about
> > > > representation and that what I want is possible with the data
modeled
> > > > via the RM and then handled with another product in front of that.
I'm
> > > > showing that the RM is all about representation. As soon as you
decide
> > > > to use another representation, you are moving away from the RM.
> > >
> > > I don't know who told you that lists are somehow only representation
> > > while sets are not, but that is nonsense. The reason to avoid lists is
> > > far more mundane and practical; it would make the DBMS more complex
and
> > > make tasks such as query optimization, concurrency control and
integrity
> > > maintenance harder. It would also make the theory more complex, which
in
> > > the long term usually also translates into practical problems.
> >
> > I do not agree with this. Conventional ordering (and hence listing) is
> > mathematically impossible in the relational model period, due to the
> > Codd's redefinition of RM-relations and the model's closure. Dawn is
> > hence correct imo - lists must be interpreted by a process external to
> > the RM, not for the sake of simplicity, or query optimization, but
> > rather because the very the nature of that data model precludes their
> > implementation.

> I agree (I guess it makes sense that I would agree with you agreeing
> with me). While ordering functions (SORT) may be defined on sets,
> those are orderings on values. There is no ordering within the
> relational structure itself.

> Of course you can simulate an ordered list using relations by adding in
> ordering attributes and related functions such as insert & delete.
> That could all be done behind the scenes without the programmer
> touching the ordering attribute at all. But once the interface to the
> user (programmer) has these features, it is no longer an RM interface
> because it supports ordered lists. --dawn

Talking about the relational model of data and the "list model of data" instead of the relational data model and the "list data model" what is the advantage of one over the other when modeling the following problems:

1. The problem is naturally formulated in terms of named lists of items and lists operations. How would you implement this with sets and sets operations ?
2. The problem is naturally formulated in terms of named sets of items and set operations. How would you implement this with lists and lists operations ?
3. The problem is naturally formulated in terms of sets and lists with their operations. How would you implement this with lists and lists operations ? How would you implement this with sets and sets operations ?

There is a need for an efficient model to support both sets and lists ? What are the basic operations for combining lists and sets ?

Where do we stop ? Why not asking for a model to support all mathematics ? Received on Mon Jan 30 2006 - 09:45:01 CET