Wow! TEXT MARKS, I had forgotten that they existed. Is there a command to
pull them out because I have obviously forgotten that to. Using FIELD plus
COL1() and COL2() seems a bit more messy.
Peter McMurray
"Lance" <ljahnke (AT) datalink (DOT) com> wrote

depending on the platform, you can RAISE them so they are SVMs, I
think.

Brett

hope your code doesn't need to be maintained by others...must be a real
fun to debug

and while you are at it try
REC(1)<1>='RED':@vm:'BLUE'
REC(1)<2>='S':@svm:'M':@svm:'L':@svm:'XL':@vm:'S': @svm:'M'
REC(1)<3>='LONG':@tm:'SHORT':@svm:'LONG':@svm:'LON G':@svm:'LONG':@tm:'SHORT'

Lance wrote:

Not really. You wont have an association between all three attributes
of colour, size, and sleeve length.

I.e Red may come in long sleeves, and red may be available in XL, but
you couldn't say you have Red, long sleeves in size XL.


Yikes. Have fun with that set-up.


--
Kevin Powick

Jeffrey Kaufman wrote:

Ok, so the example is contrived. Some would argue each size should be
a different SKU as well. Makes historical sales reporting a lot easier
down the road.

--
Kevin Powick

Electric_Monk wrote:

Yup.


--
Kevin Powick

Frankly, I see nothing wrong with that setup. That looks like a (somewhat)
complex inventory file, where the values like LONG, RED, XL, etc would come
from other tables (INV.SLEEVE.SIZES, INV.SHIRT.COLOURS, etc, which could be
simple tables [available colours only], or more complex themselves [item,
MV's list of available colours for each item]).

Of course, you would need a bit more data in this file to really give you
what you need (eg, number in stock, number on order, etc). It wouldn't be
too tough to write reports and update subroutines against this file if this
were the case. (OK, it may be tough if you're not a programmer, but I'm
assuming most of us are programmers here, and that's our job).

Sub-values are one of the beautiful things about MV programming, and whether
they are part of a data file, or built dynamically for use in one program, I
use them quite a bit.

Mitch

"Kevin Powick" <nospam (AT) spamless (DOT) com> wrote

Kevin Powick wrote:
I agree. I do think it is interesting how multivalues are very
helpful, but you immediately get diminishing returns from employing the
same idea to deeper levels. I don't see anything about this in current
XML literature (although I haven't read it all). As soon as folks are
persisting and querying XML in a bigger way (rather than primarily
exchanging it or googling it, as with xhtml), I wonder if this will
show up. I would think that MV best practices for data modeling would
help in developing best practices for XML or other NF2 data as well.

Cheers! --dawn

Well, my intent was an exercise in demonstrating the use of text marks
in relation to sub-values. Not to produce a viable solution to any
specific problem. The best solution will come from knowing all the
possibilities and selecting the one that is best for the problem at
hand and the environment in which the problem exists. In addition to
color, size and sleeve length, don't forget about season, department,
class, style and store. <wink>

it's been quite a while since i poked my head in (hey, jeff!)

....this has been one of my pets, too. i've been confortable with a
solution and weighting the priorities required here for which i've
normalized through the aid of the following:
1) every problem (since i'm a solutions person, i simply call them
"applications") will eventually grow to becoming a data-base problem
across any discipline and meta-level. therefore, to allow for maximum
growth and without boxing oneself into a corner, one must generalize
from the outset as if each discrete problem is a database problem --
including those broken down to, or built up from, the
micro/macro-levels. the same applies to data problems themselves
(conveniently allowing us common meta-meta application of generalized
solutioning.) whenever this is ignored (ie. that problems are database
problems), one will discover oneself reinventing the database wheel as
part of the application until you end up recreating a mini-database
management system, within a database management system, within a
database management system... within your program logic. yes, you can
do it, and it is always a fun excersize to see how far you can go
without boxing yourself in or perhaps rediscovering a new optimum
efficiency for a given solution point in time.. but why? especially
once you understand the above.
2) "optimizations" are merely optimizations. if you utilize a solid
methodology going into a scenario, your optimizations are not far
behind. further, if kept in check and on the fringe, can be readily
backed out as the system/sub-system/sub-sub-system... evolves. the
main reasons to have embedded data structures are data containment,
transactional containment and possible (but not guaranteed)
optimization in data access/retrieval (depending on circumstances, for
which it can actually become worsened as the amount of embedded data
grows.)
3) in problem solving, it's tempting to think "reductionistically" to
the point of excluding modest foresight and accepting that the first
path understood (while ignoring all others) is efficient in its
approach; but this tends to be lazy more than efficient -- and should
not be reasoned as any K.I.S.S. paradigm.
3) to apply the above to the thread's discussion, imagine yourself the
application, the executive program responsible for the data. your job
may be initially to simply add more data elements. okay, you figure
it's just a handful so what the heck, i'll just iterate through the
data elements and search for the controlling attribute, eg. the
sub-SKU, to preserve uniqueness, and then tack the item at the
beginning/end of the controlling value and associated dependent
values/subvalues/sub-subvalues... it's just a handful of code. Then
you figure, why iterate through to my index-point when I can get there
with a LOCATE? Next, you'll find some need to sort the items, so either
you play around with the old bubble-sort or perhaps a more
sophisticated variation or you construct the data so you can use the
PICKBASIC SORT() statement and preserve indexing. then you figure to
simply maintain the data in a presorted sequence using the sort-feature
within LOCATE (depending on the controlling-nesting levels you want to
drop to.) unfortunately, you later determine that you need to sort by
the other dependent fields, too, so we're back to the ol' adhoc
variety. how sad, that we've butchered the entire RDBMS and
reimplemented our own simulated RDBMS to be able to store/retrieve/sort
unnormalized embedded data structures within data structures...
4) now assume complexities of today's data part requirements: assume
some inventory parts from vendors have unique SKU's for the lowest
details of the cartesian product (eg. for each Style, Material, Finish,
Color, Size, Options, Unit). Others parts may have unique SKUs only
for each Style-Size-Unit grouping; others for each Style-Unit grouping;
others for each SIZE-Unit, etc. Next, the vendor may require a unique
multi-part key for certain pairings with/without unique sub-SKUs (eg.
Major Part#, Rocker, Blue, Matte, Large, $25 -- when paired together
define the discrete order to the vendor.) Similarl issues exist for
efficiently associating the PRICING to intermixed associations of
DIADs, TRIADs, etc. -- easily & potentially requiring a full cartesian
product or 2^^7 permutations in this example of
Style-Material-Finish-Color-Size-Options-Unit.
5) Finally, in determining our priorities, a good variable to help
visualize the problem is shifting our attention to the presentation
side and recognizing the complete underlying data access requirements:
especially when you want to economize on screen real-estate. here's
where the real fun begins... suppose we want to do a web presentation
from a catalog of 100,000's of items with an intuitive UI (and for
which a user is not ordering by SKU). importantly we do not want to
have present the user with 2^^7 primary variations on the screen or
even 10 when we can get away with one main one and have various
uniquely-paired drop-down boxes for each attribute (eg. style,
material, finish, color, size, options, unit, price) under
ultra-sophisticated rules. unfortunately the dependancies between
these attributes will vary by part number. for example. if i buy a
T-shirt and (S,M,L,XL,XXL-sizes) all have the same price, then i don't
need to have unique pricing for them -therefore not requiring a noisy
screen and only requiring a drop-down for size. but maybe a fur coat
has a premium on XXL, so i either create and present separate major
part items (which i don't want to have to do) -or- i explode the
cartesian out fully for all of Size-Price -or- i explode a partial
cartesian out on: S-M-L-XL-PRICE1 and XXL-PRICE2 (in a UI that
maintains the pairing.) This becomes complex when (on a part-item
basis) certain paired attributes align in relationship while others do
not. For example Finish may be PRICE-independent and certain Sizes are
only allowed for certain Finishes, as simply one example.

Understanding the above data manipulation/access requirements otherwise
performed by an RDBMS, it would easy to become innundated with
additional code complexity especially should the code also have to
totally reimplement the logic for an RDBMS sub-system intermixed with
the business logic -- and simply to embed nested data-elements to
possibly save a disk I/O? Further as the number of sub-elements grows,
the disk I/O savings becomes lost and in fact worsened for each
additional data-frame that the item grows in size by. By focusing on
the solutions for number "5" above, you will be pleased with the
resulting data structures.

Regards! -dave