Re: MV Keys

Bob Hairgrove wrote:
> Marshall Spight wrote:
>

>>mAsterdam wrote:
>>
>>>dawn wrote:
>>>
>>>>... What does it mean that a list is a key?  If
>>>>I change one value in the list, does that make it a new key?  I would
>>>>think so.
>>>
>>>If I change the order of the items in the list,
>>>does that make it a new key? I would think so. (See below)
>>
>>Sure. If you change the order of the bits in the int,
>>that makes it a new key as well.
>>
>>If you make a logical change to the value, it's a different value.
>>(Likewise, if the logical value stays the same but something
>>else changes, it's the same value.)

If it is we have a list of toppings.
If it isn't we have a set of toppings.

(David was sighing about some *very* long winding threads about this).

> But the ordering of the bits in an integer is significant,
> whereas the ordering of ingredients for a pizza isn't (although I'd
> definitely want to make the crust before I put the tomato sauce on
> it<g>).
>
> One of the fundamental things in RM is that the Cartesian join of two
> relations is commutative. Think about the implications of this when
> trying to decide what requirements a MV key would have to fulfill.

If it is possible to define a generic macro (or as Date calls it 'shorthand'), which expands/rewrites the relation with a MV key into a set of relations with only single value keys, the commutativity is not lost in the result.

I suspect that this is easier for set-keys than for list-keys.

> In Joe Celko's book "SQL for Smarties", there is an example of a
> schema for an airline scheduling system which he uses to illustrate
> DKNF (starts at the bottom of p. 35). How would someone model this in
> a MV database? In this and similar threads here, when people talk
> about the virtues of MV vs. RM, there is a perceived (by me) lack of
> any real-world examples on the MV side that go beyond trivial things
> such as stuffing lists of people's phone numbers and e-mail addresses
> into one ... (hm, I almost said "column" ... I guess "field" would be
> more appropriate here). It would be nice to see an example of
> something that would also scale comfortably beyond twenty rows or so.

Disclosure: The only things I know about MV databases is from what Dawn and some (other?) pick adepts tend to write about it in c.d.t.

In the current discussion I read for 'MV Key' simply Multiple-valued key: an identification consisting of an arbitrary number of values. Received on Sun Feb 26 2006 - 21:46:17 CET