Re: A Logical Model for Lists as Relations

From: Bob Badour <bbadour_at_pei.sympatico.ca>
Date: Wed, 10 May 2006 16:33:00 GMT
Message-ID: <0Bo8g.5951$A26.151290@ursa-nb00s0.nbnet.nb.ca>

Marshall Spight wrote:

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

Since I never said there is only assignment, I wonder why you would bother mentioning your lack of convincement. The issue is the RM proscription against imperative operations on things other than relation variables.

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

I have yet to see a character string implemented as a list except in list-only languages.

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

As is a convenient shorthand for the quota queries. Your point?

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

So, there is no useful distinction between a list and an array or between a list and a relation or between an array and a relation. I suggest that resolves your original questions.

  Maybe triggers, but I think I like the
> library idea better.

I marvel that you somehow jumped from "no useful distinction" to a triggered procedure. Since the array/list notation is just a convenient shorthand for existing relational expressions, I fail to see a requirement for either a library or a triggered procedure.

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

I don't know. I am good with leaving things at "no useful distinction".

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

Okay. And the model has no useful distinction from "relation".

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

Luckily, we have established from your above answers that a list has no useful distinction from a relation so we do not need to use links and closures per se.

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

But if the type has "no useful distinction" from a relation type, doesn't the dbms already allow multiple representations and already provide physical independence?

>>What sorts of payloads can one put in lists?

>
> Just like relations: anything. Multiple attributes per element.

Well then, it sounds like we don't have any use for lists if we already have relations. Received on Wed May 10 2006 - 11:33:00 CDT