Re: A Logical Model for Lists as Relations

From: David Cressey <dcressey_at_verizon.net>
Date: Wed, 10 May 2006 17:48:34 GMT
Message-ID: <SHp8g.5136$Rf6.4611_at_trndny05>


"Frank Hamersley" <terabitemightbe_at_bigpond.com> wrote in message news:Mjl8g.1287$S7.282_at_news-server.bigpond.net.au...

> As Bob mentions in his post // to yours, a general solution would arise
> if the list tuple had a foreign key (or two for doubly linked lists)
> identifying the next (or previous) tuple. This design whilst requiring
> more than 1 "IO" per insert remains linear in cost.
>
> The ordinals if needed could then be produced on retrieval although the
> cost could become prohibitive. Others may be able to affirm that
> algorithms exist to produce these on the fly.
>
Frank,

Just as a side note on your comment above.

I have seen a design for an Oracle database based on doubly linked lists, implemented as described above. It was one of the wretched designs of all time.

NOT because there's anything unsound about what Bob suggested. Rather, because the same information requirements could have been met by designing the list to be a set, instead. I forget the details, but the problem domain called for (practically screamed for) a set oriented design. The actual design seemed like the designer was steeped in CODASYL and under the influence of some psychtropic substance. It had all the drawbacks of a CODASYL datbase, together with the added overhead of an SQL implementation.

If there's a point to all this, here it is: use sets where sets are useful, and use lists where lists are useful. Know the difference. Received on Wed May 10 2006 - 19:48:34 CEST

Original text of this message