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

JOG wrote:
> Marshall Spight wrote:
> > David Cressey wrote:
> > > "mAsterdam" <mAsterdam_at_vrijdag.org> wrote
> > >
> > > > If I change the order of the items in the list,
> > > > does that make it a new key? I would think so. (See below)
> > >
> > > In other words, an onion and mushroom pizza is different from a mushroom and
> > > onion pizza.
> > >
> > > Here we go again.
> >
> > Ha ha!
> >
> > I've always maintained that any question about whether a collection
> > is ordered or not (such as a collection of pizza toppings) is a
> > question of domain modelling. The question of whether
> > onion, mushroom = mushroom, onion is exactly the question
> > of whether this particular collection is considered ordered
> > in this particular domain. To answer that, we need a
> > domain expert.
> >
> >
> > Marshall
>
> Yes! This point is crucial and why (dawn ;) one should desperately
> avoid the conceptual squashing of sets, multisets, orderings, peruvian
> monkey fish, etc., into a single catchall "list" construct.
>
> It isn't just about the pros and cons of passing cognitive load onto
> the user, its about allowing the system to be capable of maintaining
> integrity and making formally correct decisions. As far as I can see,
> the domain expert that Marshall specifies above can and *should be* the
> system itself,

Would that the domain expert were the system -- it would be so less likely to change its mind. But, yes, I agree that when you store sets or monkey fish in a list, you are bound to encounter some issues where it would be better for the system to have the information that this is, indeed, a set or a monkey fish and not a list.

> as defined to it at design time when the domain was
> specified.

And redesigned in subsequent projects as requirements change. So, yes, I agree with you in theory, but I'm hedging related to practice. --dawn Received on Mon Feb 27 2006 - 04:31:11 CET