Re: By The Dawn's Normal Light

From: Paul <paul_at_test.com>
Date: Sun, 24 Oct 2004 16:11:53 +0100
Message-ID: <417bc639$0$43599$ed2e19e4_at_ptn-nntp-reader04.plus.net>


Kenneth Downs wrote:
> If the list is uniquely ordered I think you can do everything 1st order.
> The inserted item must be either head, tail, or have defined before and
> after nodes. You should also be able "SELECT..WHERE sequence>x" to get all
> items after item x. Don't know if you can guarantee unique sequence #'s on
> inserts without an occasional resequencing, like an index reorg. This
> seems to be the absolute positioning case.

But then if you wanted to insert a new entry at the beginning you'd have to shuffle all the higher entries' sequences up, which would be a second-order operation.

Unless you use an "dense" domain e.g. rationals and stick in non-integers when you want to insert a new entry between two adjacent integers.

Actually, as you can map integers to rationals one-to-one, you could even use integers as the sequence numbers, as long as you accept you're going to have to use a non-standard ordering.

Maybe this is the way to do it then.

I guess this way you're relying on "borrowing" the ordering from an existing ordered domain, but this shouldn't matter too much really. Maybe this part is hiding the second-order logic from the relational engine inside the existing ordered domain definition.

The only constraint you'd need is a uniqueness constraint on the sequence column I think.

Are there any downsides to this method over the relative positioning method?

I suppose what it's saying is that to get you started you just need a single infinite list e.g. the integers (you can hide the second-order details here). Then all other lists can be mapped to that one using first-order logic. Instead of deriving each list from first principles, requiring second-order logic each time.

Paul. Received on Sun Oct 24 2004 - 17:11:53 CEST

Original text of this message