Re: Reminder, blatant ad

x wrote:
> "dawn" <dawnwolthuis_at_gmail.com> wrote in message
> news:1138627814.473060.169280_at_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 ?

>

>

>

That would take a smarter man than I. I'd be fine with the java.lang libraries. They are well documented. ;-)

>

>

>

I'm very flexible that way, which means to me that I'm a bit of a peasant in that regard. I like functional and OO languages, but once upon a time I adored procedural languages too and can tolerate declarative languages.

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

>

>

What works for me is what I would call a di-graph of trees (a tree on each node of the graph). You can see an example of this with html (or xhtml) pages. You have a DOM tree (web page) on each node of a di-graph (web). That is, effectively, what Pick is too, although the tree doesn't go as many levels deep as the DOM.

> Can you make such a thing declarative (specifying the data, not the process
> of getting the data) ?

I can tell that you will love (and perhaps dislike) my next blog. While I can understand the advantage to an exclusively declarative language, I like verbs too. In the end, computer software is going to process data. Making process fixed, but reusable (in the form of DBMS tools) while the data patterns have to be perhaps overly clever (to accomodate the declarative language constraints) and be coded fresh each time, doesn't strike me as particularly fine.

If we had gone another route and made reusable data entities such as Person, Address, Product, Order, etc building up to vertical industry models with developers preparing the processes, would our profession look different? Don't get me wrong, I think declarative languages are important in the mix and have some benefits, but I am not fixed on that as the ultimate goal.

--dawn Received on Mon Jan 30 2006 - 18:33:37 CET