Re: A Logical Model for Lists as Relations
Date: Wed, 10 May 2006 16:33:00 GMT
Message-ID: <0Bo8g.5951$A26.151290_at_ursa-nb00s0.nbnet.nb.ca>
Marshall Spight 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 - 18:33:00 CEST