Re: MV Keys

David Cressey wrote:
> "dawn" <dawnwolthuis_at_gmail.com> wrote
>
> > > a evaluates to a list: (onions, mushrooms)
> > > b evaluates to a list: (mushrooms, onions).
> > >
> > > Somewhere a data definition has been made available to the engine that
> says
> > > that for the particular type of list that a and b are, the proper
> > > evaluation is "TRUE".
> >
> > Ah, OK. In MV, all lists (all data) are strings. Then list "a" simply
> > isn't the same as list "b". A programmer might decide to check if they
> > represent the same bags or sets even if the lists are not the same.
> > That might require a sort.
> >
>
> OK. So, if I use an MV to store a set of toppings in a list, I've indulged
> in a little misrepresentation.
>
> In the list, according to what you've just said, a pizza with onions and
> mushrooms is not the same as a pizza with mushrooms and onions.
>
> Now let's say I'm doing market analysis on three months worth of pizza
> orders. I've got an MV key that represents a list of toppings. (Well, it
> really represents a set of toppings. I know that because I'm the
> programmer). But a different programmer gets assigned to do the report.
>
> That different programmer does what amounts to a GROUP BY, programmatically,
> in order to compute some aggregate statistic for each group of pizzas,
> according to toppings. But, of course, the programmer gets two different
> groups for (mushrooms, onions) and for (onions, mushrooms). Each of these
> groups is less profitable than the group (onions), but together they account
> for more business than (onions). The report decieves management, because
> the programmer got deceived.

Yes, you've got it on the nose with that one. Different conventions, standards, and communication approaches are used to mitigate this, but it is anything but airtight. Each data model has risks associated with it and this is one with the MV approach. Because reporting is so easy and reports are more conceptually aligned (see the blog entry just posted at http:/www.tincat-group.com/mewsings ), such issues are typically readily found during testing, but that is surely not guaranteed.

> The programmer that created the report got deceived by making an inference
> about the meaning of an MV key that I, the programmer that wrote the data,
> did not intend. How is this sort of thing prevented in MV?

It is not prevented, but mitigated. If equality of two lists will be important, then the developer might build in a routine that sorts the order by some attribute (alpha, for example) before writing the list back. But they might not or, as we see all the time in BI efforts, the original developers and users did not perceive any such requirement, but down the line it was required for analysis. The the BI developer sorts before comparing. Every solution has risks to be mitigated.

Cheers! --dawn Received on Wed Mar 08 2006 - 17:02:16 CET