Re: MV Keys

In article <AcWOf.44985$H71.27027_at_newssvr13.news.prodigy.com>, brian_at_selzer-software.com says...
> That's my point. Blue has identity within the universe of discourse. To me
> it seems more logical to talk about blue, not blue that can be the first
> element in a list, blue that can be the second element in a list, blue that
> can appear in a list more than once, blue that can be the only element in a
> list, blue that can be in the same list as yellow, blue that can come after
> yellow, etc.

Um... yes. There is only one blue; that it can be used in different context with different meanings doesn't change that, and doesn't cause any redundancy.

> If the list (1, 1, 2) has been stated in a database, they're indeed
> different, because the position in a list augments the meaning of each
> element in the list.

The interpretation of the number might be different, but the number remains the same. If I have three cats and three aunts, do I have the same number of cats and aunts? Yes. With no redundancy. Whether I store cat-and-aunt-counts in two columns, or in a single list-valued column (constrained to lists of size 2) makes no difference redundancywise.

> >> This problem becomes more immediate if you consider
> >> active objects. Assuming you have a domain for widgit objects, and a
> >> domain
> >> for lists of widgit objects, how can you discern which widgit you're
> >> talking
> >> about? Are they the same widgit, or are they separate instances with the
> >> same property values?
> >
> > Now you are talking about variables, not values.
> >
>
> No, I'm talking about redundancy and the problems caused by it.

No, variables. You talk about something that can be changed (isn't that what you mean by "active"?), and still retain its "identity". That's a variable, not a value. Values can't change.

> Once you discard First Normal Form, all bets are off.

What bets? Are you saying a database not in 1NF is logically unsound/inconsistent? 1NF is orthogonal to the other usual NFs, except if you arbitrarily define the others to include 1NF.

> > If there can be more than one (as it seems there can be, assuming a
> > person can only have two parents), it is not a good idea to use the name
> > to identify her. In that case, you have a list of names, not a list of
> > children---and there is only one "Mary Smith" name. But this also has
> > nothing to do with list attributes.
>
> It certainly has something to do with how list attributes can be abused.

But you were trying to demonstrate the inherent redundancy introduced by list attributes, not redundancy caused by bad DB design. Anything can be abused; list attributes perhaps more so than other things---but they are not fundamentally harmful.

> >> Assuming that you can determine Mary Smith has Bob
> >> Smith as a parent, don't you have to also update the list associated with
> >> Jane Smith?
> >
> > I'm not sure what you mean here, since (a) Mary Smith is already present
> > as a child of both Bob and Jane. But (depending on you definition of
> > "having children", of course) I'd say you wouldn't necessarily have to.
>
> Are you related to Slick Willie? "Depends on the meaning of the word 'is'"
> sounds suspiciously like "depending on your definition of 'having children'"
> to me.

Please. If Bob has a child, does Jane have the same child? You seem to assume so; I guess because in your mind, Bob and Jane are a couple, and wouldn't dream of having a child with someone else---alternatively, that since they are a couple, any child one of them has, the other also has in some legal sense. I tried to question your definition of "having a child": does it mean being the biological parent? Or the legal guardian (or whatever the term is; English is not my first language)? Or married to a biological parent? How do you know what the relationship between Bob and Jane is anyway? All this is crucially important for how your database should behave, so it makes little sense to talk about update anomalies and redundancy before this is clear. It may be clear in your mind, but you haven't communicated it.

-- 
Jon