Re: Sets and Lists, again

From: David Cressey <dcressey_at_verizon.net>
Date: Tue, 23 May 2006 11:16:58 GMT
Message-ID: <KaCcg.2552$J95.337_at_trndny05>

"dawn" <dawnwolthuis_at_gmail.com> wrote in message news:1148341342.580083.39780_at_y43g2000cwc.googlegroups.com...
> David Cressey wrote:
> > "dawn" <dawnwolthuis_at_gmail.com> wrote in message
> > news:1148165794.460453.268180_at_38g2000cwa.googlegroups.com...
> > > David Cressey wrote:
> > > > "dawn" <dawnwolthuis_at_gmail.com> wrote in message
> > > > news:1148132310.308203.133240_at_g10g2000cwb.googlegroups.com...
> > > > > David Cressey wrote:
> > > > > > What's a ripple delete? How is it different from an ordinary
> > delete?
> > > > >
> > > > >
> > > >
> >
http://www.tincat-group.com/mewsings/2006/01/who-ordered-ripple-delete.html
> > > > >
> > > >
> > > > Can you summarize this?
> > >
> > > I was hoping the first few sentences did that, sorry. It is a delete
> > > that also renumbers or moves up subsequent data. In the case of a
> > > desired alpha ordering, this is simply a delete. In the case of a
list
> > > or a numbered 1,2...n set (the number being an attribute in a
relation,
> > > for example), removing the 3rd and 4th elements requires renumbering
> > > all of those after it.
> > >

Thanks for the clearer definition. The necessity for a ripple delete comes out of the nature of lists, and is not inherent in the data represented in each list element.

If we say that "Monroe was the 5th president of the United States", that's NOT an attribute of Monroe. It's an attribute of Monroe's membership in the list of presidents. If someone were to assert that "John Hancock was the real first president of the United States", then a consequence of that assertion would be that Monroe was really the 6th. Nothing has changed about Monroe. It's the list that has been changed.

> > > > > > If you have sets, why would you have to "insert at this point"?
> > >
> > > In the case of sets that are numbered as above, inserting a new 5th
> > > element requires that 6...n be renumbered. Have you ever seen the
> > > design often used with "relational databases" where you leave a range
> > > of 10 or n numbers on either side of numbered items so that you can
> > > stick new ones in up to the number of spots reserved? You don't need
> > > to design that way if using a list where the numbering is behind the
> > > scenes because the structure is a logical list.
> > >
> >
> > If you have lists, you have to renumber every time you retrieve the
list,
> > if you desire ordinal numbers to indicate position in the list.

>

> I'm working at the logical level where an index holds the ordinal
> position. This position can be selected just as any attribute (derived
> or otherwise). There is no renumbering required.
>
The index has to do the renumbering.

> >
> > > > [no reply]
> > > >
> > > > Again, what does "insert at this point" buy you that insertion into
a
> > set
> > > > doesn't buy you?
> > > >
> > > >
> > > > > > Why do you need lists for this purpose?
> > > > >
> > > > > ? Why do you need lists for the purpose of having list operators?
> > Can
> > > > > you rephrase?
> > > >
> > > > Sure:
> > > >
> > > > What can you do with lists and list operators that you can't do
with
> > sets
> > > > and set operators?
> > >
> > > That is similar to "What can you do with a high level language that
you
> > > could not do with assembler?" Ease of development and maintenance
(aka
> > > cost savings). --dawn
> > >
> >
> > That's no explanation at all, Dawn. Your reply presumes that list and
list
> > operators are "higher level" than sets and set operators. It seems to
me
> > that it's just the reverse. And I think the history of programming
languages
> > supports my view. Languages that support lists and list operators
predate
> > languages that support sets and set operators.

>

> For the problem domains I have worked with, nothing could be done with
> one that could not be done with the other data model. When a list is
> logically modeled as a set, more work is required, however. So for the
> typical business data processing application, the RM is simply a more
> primitive means of modeling a list. It is similar to working with
> assembler when one could use a higher level language for the average
> use. Do you still disagree with that assessment? --dawn
>

ABSOLUTELY! For the problem domains I have worked on it's just the reverse. When a set is logically modeled as a list, more work is required. For the typical business application, a list is simply a more primitive means of modeling a set. Your view and mine couldn't be more opposite.

Converting a set to a list is absolutely trivial. Consider the following:

     select ROWNUM, PRESIDENT_NAME
     from  PRESIDENTS
     order by ACCESSION_DATE;

(Other readers please note: I am NOT endorsing the use of ROWNUM. It leads to a host of difficulties that can be described as the unfortunate consequences of treating a set as though it were a list.)

Converting list to a set is far from trivial. One of the reasons I liked Datatrieve is that it would do that for you. Received on Tue May 23 2006 - 13:16:58 CEST