Re: Reminder, blatant ad

From: dawn <dawnwolthuis_at_gmail.com>
Date: 30 Jan 2006 05:30:14 -0800
Message-ID: <1138627814.473060.169280@g14g2000cwa.googlegroups.com>

x wrote:
> "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:

>

> a) 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 ?

>

> b) 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 ?

>

> c) 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 ?

Yes.

> What are the basic operations for combining lists and sets ?

The ones that come with any general purpose programming language.

>
> Where do we stop ?

I'm good with programming languages as a "stopping point" building up from there to higher levels with libraries of code.

> Why not asking for a model to support all mathematics ?

Again, I'm good with programming languages and libraries thereof. smiles. --dawn Received on Mon Jan 30 2006 - 07:30:14 CST