While I see a lot of reason to design with multivalues, including
associated multivalues, up front in a project, I don't use sub-values.
If I get to that point, I redesign into a separate table. My reasoning
is that multivalues are conceptually easy and easy to report against,
while sub-values are more difficult on both fronts.

I can understand slipping in a sub-value, however, once a system is
underway, if there is a real need and the cost of doing so seems low
enough for the long haul.

Do others design up front with sub-values? In what cases? Does anyone
have any rule of thumb for when you use them or don't use them? These
questions and more...

Cheers! --dawn

"dawn" <dawnwolthuis (AT) gmail (DOT) com> wrote

I have always use subvalues to handle the "shipped" part of order
processing because they fit neatly into the real world. Shipments are MVs
of the order quantity usually based on ship date but sometimes based on a
combination of ship date and a serial when there are multiple shipments the
same day. Returns then become subvalues. There are some variations to
consider like re-ship or refund but these also seem to fit neatly into
subvalues. In general however subvalues can really be confusing when
changes are required.
BobJ

"dawn" <dawnwolthuis (AT) gmail (DOT) com> wrote

Dawn-

Some implementations do a better job with access reporting on sub-values
than others. However, in practice they have proven more useful in control
records that will be manipulated by programs only, rather than reported on
thru the report generator.

This is due to both the unreliable nature of code portability to other
platforms and because many people have enough trouble with multivalues
without adding another level of detail in the mix. Also keep in mind that
MV likes "lots of small records" in a file (table) and adding more levels of
values tends to enlarge the records with little gain.

YMMV

BFaux ;-)

Dawn -

Ken Simms, the fellow who initially put together the Basic system at
pick systems, lost a big argument with Dick Pick. His notion was to
implement "line item" as a data type, so that an attribute could be a
list of these data. The implementation proposed was for incorporating
the type into the retrieval language ("english") with a decimal
notation, so attribute 3.2 was the 2nd line item in attribute 3. I
don't know the complexity of the implementation throughout the system,
including in his Basic system, but certainly it didn't seem high. The
big objection was simply that it was aesthetically rude. It was an
assault on the simplicity of the model.

I thought the "line item" was a natural data type (a list) and in my
coding structures built in all I needed for handling it. Very xml-ish
for attribute values. Very simple code. Very natural modeling and
design. Very stable migration and enhancement. and it solved most of
the correlated attribute problems, at the cost, in my version, of
reserving the '_' character as a delimiter.

The line item elements could be viewed as sub-values logically (eg the
price field of the order line), but didn't address the is-a-part-of
recursion of values of bill of materials processing. Limiting the
definition of 'multiple' to mean 'up to 3' never did make sense to me,
and is possibly the greatest aesthetic rudeness in the mv model. And
besides, as you are exploring, the frequency of needing a model for
additional depth is low; the frequency of needing to describe values of
things as lists of their constituents is very very high. There was a
performance gain in the early machines, where picking up the line item
elements in other files/tables was magnitudes slower than converting the
element out of the the line item value.

So, design with "line items" yes, with atomic attributes, no, not beyond
the second value. I nearly never saw the practical need to have a 3rd
level - a list of the elements of a line item element, but perhaps that
reflected either a limit of my imagination or of the complexity of
applications I designed.

I really would prefer to refer to LoL data systems, rather MV data
systems, as Lists of Lists is to me the central strength (along with the
the character-delimited attributes). Or just V data systems (for
Virtual), as constraints to the lists (type, sequence, integrity, ...)
can be applied externally or not, as one desires, just as the physical
representation does not limit the logical structure.

--
Bill

dawn wrote:

Word.

--
frosty

There is a major software house I worked for which uses subvalues,
sub-subvalues, and sub-sub-subvalues, using their own globally-implemented
subroutines to handle the 2 extra ascii codes to represent them. They raise
and lower as needed in order to manipulate them with standard Universe
constructs. It's all over the system, in data records as well as control
records, and it works well. Take some getting-used-to though.

Ed

"dawn" <dawnwolthuis (AT) gmail (DOT) com> wrote

Hi Bill
It is a pity that Ken lost the argument. However people still try to do it
unfortunately. Originally the 32k limit made it a disaster at places like
Datamail in South Melbourne. Nowadays some banking systems for instance are
a real mess to follow.
The major problem in doing this is that the records just get bigger and
bigger when they really should be in a sub file. An invoice is a natural
for this line item approach however people go and try to use it for say a
bank customer's transactions and the whole thing becomes a monster.
Peter McMurray
"Bill Cooke" <bcooke (AT) cookedata (DOT) com> wrote

We use sub-values mostly for index and cross reference files. It is very
easy to use the locate statement to find record identifiers, do counts, do
loops, etc.on the sub-valued attributes.

INVENTORY-HIST-INDEX
<0> year * month * branch# * sku#
<1> history id's for sales ]
<2> history id's for purchases ]
etc.

I remember the old days with the 32k limit we had to do stuff like this:

SEQ=0
10 READ REC FROM XFILE,WORD THEN
IF LEN(REC) >32000 THEN
SEQ=SEQ+1
WORD=WORD:"_":SEQ
GOTO 10
END
REC<1,-1>=ID
END

Jeff

"Excalibur" <excalibur21 (AT) bigpond (DOT) com> wrote

I agree. I have designed probably over 100 systems. Although there are
places where sub-values are needed, as a general rule, I find it best
to avoid them if possible. - Steve

On 4 Apr 2006 09:02:33 -0700, "dawn" <dawnwolthuis (AT) gmail (DOT) com> wrote:

Never, all you get is a big mess...eventually.
So far all the designs I've seen where sub-values where used ended up
in a disaster. Sure there might be some which do work but for long term
benefit I would avoid them at all costs.
But thats just my opinion.

M

dawn wrote: