Re: A Logical Model for Lists as Relations

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

Phew, it must have been bad 'coz premier status in that category is heavily contested.

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

I most wholeheartedly concur.

However given the problem has been set, I am interested to observe any state of the art that might be presented in CDT.

I have on rare occasions felt compelled to use "ordinal generation" in SQL and knowing my queries are perhaps quite kludgy have been at great pains to constrain the number of tuples to limit the damage visited on the host. Hence my interest in any best practice offerings.

Cheers, Frank. Received on Thu May 11 2006 - 01:58:39 CEST