Re: MV Keys

mAsterdam wrote:
> dawn wrote:
> > mAsterdam wrote:
> >
> >>dawn wrote:
> >>
> >>>... 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.
> >>
> >>If I change the order of the items in the list,
> >>does that make it a new key? I would think so. (See below)
> >
> >
> > Yes, I too often mix sets & lists when I think in terms of the MV data
> > model, which has only list attributes in which conceptual sets & lists
> > are both implemented.
>
>
> Really? Are sets implemented as well?

In MV, functions (sets) are like files with a primary key. They permit list values for attributes as well as single values. All attributes are ordered and the values within them are ordered and the sub-values within them are ordered. It looks very much like a compact version of XML with "markers" (specific ascii codes) separating records, attributes, values, sub-values instead of metadata strewn throughout. The other difference is that you don't go more than a couple of levels deep in the nesting in MV compared to the possibilities for nesting in XML. Cache' (MUMPS) has more nesting. I have never encountered a need for it and it seems to help with conceptual simplicity not to have more nesting available within a single file.

> I thought it was more like this:
> When you have a model only supporting lists (e.g. XML) you have
> no choice but to implement any multi-value thingy as a list - wether
> you initially thought of it as a set or not.

Yes, that is precisely the case with MV, which I think of conceptually much like an XML database without the performance and other issues. If the toolsets were a bit more modern (I'm still trying to figure out what such improvements might be needed), it would much more obviously meet the needs of today's s/w development than other tools, I think. Cheers! --dawn Received on Sun Feb 26 2006 - 20:25:16 CET