Re: Sets and Lists, again

From: dawn <dawnwolthuis_at_gmail.com>
Date: 23 May 2006 04:27:43 -0700
Message-ID: <1148383663.147655.295060@j73g2000cwa.googlegroups.com>

David Cressey wrote:
> "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,

But what about modeling lists? Would you not suggest that modeling a list as a set introduces complexity?

> more work is required. For the typical
> business application, a list is simply a more primitive means of modeling a
> set.

But is it not a better means of modeling a list?

> Your view and mine couldn't be more opposite.

I can agree with your asessment, however, especially given use of the RM. It sounds like you disagree with mine. Are you saying that it is easier to model a list as a set and define all of the required operations on that set outside of the dbms than to have lists be integral to the model?

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

>


>      select ROWNUM, PRESIDENT_NAME

>      from  PRESIDENTS

>      order by ACCESSION_DATE;


All selects convert sets to lists, whether with or without an order by
clause.

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

Yes! So why model data that way? Treat a list as a list.

> One of the reasons I liked
> Datatrieve is that it would do that for you.

In what way(s)? Thanks. --dawn Received on Tue May 23 2006 - 06:27:43 CDT