Re: MV Keys

"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.

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? Received on Wed Mar 08 2006 - 16:26:38 CET