Re: MV Keys (was: Key attributes with list values)

On 26 Feb 2006 08:19:50 -0800, "Marshall Spight" <marshall.spight_at_gmail.com> 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.)

It's not quite that simple. As David pointed out, a "mushroom and onion pizza" is not necessarily different than an "onion and mushroom pizza". 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.

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.

--
Bob Hairgrove
NoSpamPlease_at_Home.com