Re: Key attributes with list values was Re: What are the differences ...KEY

Brian Selzer wrote:
> > I definitely agree with that philosophy. It was just a
> > for-what-it's-worth - if there were some added complexity to permitting
> > list values in candidate keys, it is not a feature many would use or
> > need.
>
> It's also insane.

A very bad design from my perspective as well.

> Using a list--or any non-scalar value for that matter--as
> a prime attribute introduces ambiguity and redundancy into the data model.
> For example, if the contents of the list changes, does that signal a key
> change? What I'm trying to convey is that from one point of view, a list
> has identity, regardless of its contents.

Correct (if I understand). 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.

> So is the candidate key the list
> identity, or is it the permutation of a collection of values? Also, I was
> under the impression that redundancy is the prime target of the discipline
> of data modeling.

Although I did just learn the benefits of redundancy from Frank ;-)

> A database is a knowledge respository, and it doesn't
> make sense to "know" something more than once.

It might model a proposition something like

The team with people whose ID's are 112233 and 123456 has a best run of 38 seconds in the potato sack race.

Most data modelers would choose to provide a team identifier rather than implement a multivalued ID (even MV developers).

Cheers! --dawn Received on Sun Feb 26 2006 - 05:27:25 CET