Re: MV Keys

"dawn" <dawnwolthuis_at_gmail.com> wrote in message news:1141706092.790613.114350_at_p10g2000cwp.googlegroups.com...
>
> Brian Selzer wrote:
>> "Jon Heggland" <heggland_at_idi.ntnu.no> wrote in message
>> news:MPG.1e765d711930178098978c_at_news.ntnu.no...
>> > 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.
>> >
>>
>> I think it does. If widgits is defined as a domain and lists of widgits
>> is
>> defined as a domain, and the same list of widgits can be arrived at
>> through
>> the use of the combinatorial rules of the universe, then the explicit
>> domain
>> definition is redundant. If you define constraints on the widgit list
>> domain, but construct some widgit lists in a database without referencing
>> that domain, then those constraints cannot be enforced for every list of
>> widgits. On the other hand, you can limit the production of widgit lists
>> with a single set of constraints that can be enforced for every list of
>> widgits.
>>
>> >> 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.
>> >
>>
>> Without First Normal Form, there's no limitation on the complexity of an
>> attribute.
>
> There certainly can be. Even if sounds arbitrary, a dbms vendor can
> permit lists and not bags; nested lists, but no lists nested within
> lists; etc.
>

But we're not talking about a specific dbms, and wouldn't that eliminate whatever benefits you perceive exist?

>> Nor is there a requirement that domain elements remain static.
>> All that is required is the ability to differentiate between elements,
>> and
>> the introduction of lists impairs that ability.
>
> It is not difficult to ask if two values are equal when they are list
> values. Why do you think it would be?
>
>> >> 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.
>> >
>>
>> I can't be sure, and that's enough for me to avoid applying NFNF like the
>> plague.
>
> There's plenty of emperical data that should permit you to sleep well
> even if using NF2.
>

But that's not proof. In a system that processes tens of thousands of transactions per day, if you only have one anomaly per million transactions, the database will be corrupt in a month.

>> >> > 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.
>> >
>>
>> I think they are.
>
> Because...? --dawn
>
Received on Tue Mar 07 2006 - 12:29:24 CET