Re: A Logical Model for Lists as Relations

Bob Badour wrote:
> Marshall Spight wrote:
>
> > What about imperative operations? This is a bit more complicated.
>
> Not really. The only imperative operations in an RDBMS map to relation
> variable assignment. Lists, if you have them at all, are necessarily
> just values.

I'm not convinced that "there is only assignment" is the right design. (It certainly works as a theoretical basis, though.) If the kernel language supports only assignment, and not, say, insert, then the implementation of insert must necessarily be hugely expensive.

I hate to bring the physical into the conversation, but there are times when the logical model constrains the physical implementation, and imperative operations is one of those times.

> I think you are getting way ahead of yourself. Why do you need a list
> type?

I hate to respond with such a generic answer, but "for ordered data" is as specific as I can get. Character strings are a good example.

> What do you intend to accomplish with your index attribute that
> one cannot accomplish with quota queries and relations?

Convenience merely. But it is a *lot* of convenience.

> How does list differ from array?

Different authors use these terms different ways; for myself, I don't see a useful distinction. Maybe "list" is logical and "array" is physical? Dunno.

> How does [list] differ from relation?

It's just a special case as best I can tell. There are constraints on the index attribute(s). Maybe triggers, but I think I like the library idea better.

> Wouldn't a list
> have a candidate key and a successor self-referencing foreign key?

I don't think so; the ends of the list would make that problematic. What would it buy you?

> Wouldn't a double-linked list also have a predecessor self-referencing
> foreign key? Or do I have those reversed?

Linked lists strike me as an implementation technique rather than a useful model. The model is simply "list".

> If one links lists using
> foreign keys, can one specify the ordered relation using a closure?

Yes, but this approach is cumbersome compared to traditional list operations.

> What
> about circular lists?

> If it is a type, shouldn't a list have multiple
> possible representations? If it has multiple possible representations,
> doesn't physical independence suggest the dbms can use any of them?

Yes and yes!

> What sorts of payloads can one put in lists?

Just like relations: anything. Multiple attributes per element.

Marshall Received on Wed May 10 2006 - 16:28:58 CEST