[ic] One SKU in multiple Branches of TREE

interchange-users@interchange.redhat.com interchange-users@interchange.redhat.com
Sat Jan 12 17:45:01 2002


On Sat, Jan 12, 2002 at 02:56:40PM -0700, Gary Norton wrote:
> <cut and paste relevant part to comment on>
>      could just as well be
> 
>      Ford->Bronco->Shocks
>      SKU->Ford->Bronco
>          ->Explorer
>          ->Edsel
> 
>      Deep goo.
> <end cut>
> 
> Hmm. Interesting point on the latter item leading with SKU as a Trunk item rather than a Leaf. I hadn't even considered that. I need to think about it a  bit more, it sounds promising, but then I am stuck with a way to build Reverse Expand/Collapse tree as the user would not want their initial interface to start with the SKU, but rather the most generic category.
> 
> Ugh. My head hurts.
> 
> Perhaps I am addressing the problem all wrong. Rather than assuming that TREE is what I need, does anyone else have suggestions in implementing a hierarchal product structure that a user can browse through?

ummm, yahoo, google, dmoz, even the local library.  :-)

Note that google took the category browse off their top page.  I assume
they know wnat they are doing.  When was the last time anyone on this
list "browsed" the category hierarcy at google looking for something?

IMCO categorization, eg "how does it get found among similar items" is 
the **hardest** part of the ecommerce world.  Once you get beyond a 
handful of categories it is not trivial.

And why should "shocks" be a category?  One is not interested in shocks
that are NOT Ford -> Bronco - unless those in Explorer or Edsel fit too.

If you are building a broad structure, your head should hurt; at least
you are on the right track.

My $.02 is find someone else who has done it successfully for your
industry and piggy back on them.  Once you get that, the implementation
(tags/tree/perl whatever) is trivial.  If you really are talking about
multiple thousands of sku items in maybe hundreds of categories with cross
shelving (one item in multiple categories) then do pay attention to a good
data model.  Optimize it for searches.

Make sure your audience is right.  A woman looks up plumber under 
"profession", most males will look up a plumber under "trade", maybe 
under "building *" or perhaps under "p", etc....

Remember, this is irrelevant and counter productive advice for small 
simple structures (one layer).  YMMV.


> 
> Thanks again,
> Gary
> 
> 
> 
> 
> 
> 
> >>> cfm@maine.com 01/11/02 02:32PM >>>
> On Fri, Jan 11, 2002 at 12:22:31PM -0800, Ed LaFrance wrote:
> > At 01:06 PM 01/11/2002 -0700, you wrote:
> > >Ed,
> > >
> > >Thanks for the reply. So are you suggesting this implementation for TREE 
> > >as well, or just in reference to Multiple Categories. It seems like a 
> > >delimited field with multiple tree-branch paths could get quite ugly very 
> > >quickly. However, I may not be seeing the light at the end of the tunnel 
> > >on this either. I would think just for a normalization factor that it 
> > >would be best in a separate table, but again I am not a DBA or Perl 
> > >programer by trade. Just a newbie trying expand my skill set and 
> > >understanding.
> > >
> > >Thanks in advance,
> > >Gary
> > >
> > 
> > I was making a general observation. In all the things I have done with MV 
> > and IC, I have never knowingly used the TREE tag, so I have to stay mute on 
> > how my comments would fit into that context.
> > 
> > - Ed L.
> 
> 
> I fall into the "single field gets ugly very fast" camp.  If you suspect
> that is likely to be an issue, then it probably will be a big issue.  :-)
> 
> > >>Shocks=>Ford=>Bronco=>77-79=>SKU
> 
> could just as well be
> 
> Ford->Bronco->Shocks
> SKU->Ford->Bronco
>          ->Explorer
>          ->Edsel
> 
> Deep goo.
>    
> 
> 
> > >>>> edl@newmediaems.com 01/11/02 10:58AM >>>
> > >At 07:57 PM 01/10/2002 -0700, you wrote:
> > >>In searching the archives of the list I didn't see this addressed
> > >>specifically, but I did find mention of one SKU in multiple categories.
> > >>Basically the thread mentioned creating a separate table that listed only
> > >>sku and category (that is an abbreviated explanation of course).
> > >>
> > >>I am not sure if it is possible (usually it is if you are smart enough,
> > >>unfortunatly on this subject I am not) to do the same thing to support a
> > >>single SKU in multiple branches of a tree.
> > >>
> > >>Example: Auto-parts store sells items that are usually selected by auto
> > >>make and year:
> > >>
> > >>Shocks=>Ford=>Bronco=>77-79=>SKU
> > >>
> > >>However many SKU's can be used across multiple branches using the previous
> > >>logic (ie 81-83 etc.)
> > >>
> > >>If this is possible, what do you think the best implementation is. I had
> > >>thought about a 3rd table implementation as listed for the single sku in
> > >>multiple categories thread, but wasn't sure what would need to be tweaked
> > >>to support the TREE structure.
> > >>
> > >>I had a few ideas, but basically my brain-train got derailed when I tried
> > >>to figure out how I was going to support SEARCHING and other features 
> > >etc...
> > >>
> > >>FYI, I am testing this implementation on a generic install of
> > >>"Construct"  with the integration of the HOW TO for TREES.
> > >>
> > >>Thanks in advance,
> > >>Gary
> > >
> > >Fields like category, which are used to classify and group items, need not
> > >contain just one value - you could theoretically make one sku a member of
> > >as many categories as you want, by filling the category field with a list
> > >of delimited values.  This will require changes in the UI as well as in
> > >front-end code, but it is quite doable - I have done so many times.  It's
> > >just not implemented in the foundation demo, AFAIK.
> > >
> > >- Ed L.
> > >
> > >
> > >
> > >
> > >
> > >
> > >===============================================================
> > >New Media E.M.S.               Software Solutions for Business
> > >463 Main St., Suite D          eCommerce | Consulting | Hosting
> > >Placerville, CA  95667         edl@newmediaems.com 
> > >(530) 
> > >622-9421 
> > ><http://www.newmediaems.com/>http://www.newmediaems.com 
> > >(866) 519-4680 Toll-Free       (530) 622-9426 Fax
> > >===============================================================
> > >
> > >_______________________________________________
> > >interchange-users mailing list
> > >interchange-users@interchange.redhat.com 
> > ><http://interchange.redhat.com/mailman/listinfo/interchange-users>http://interchange.redhat.com/mailman/listinfo/interchange-users 
> > 
> > ===============================================================
> > New Media E.M.S.               Software Solutions for Business
> > 463 Main St., Suite D          eCommerce | Consulting | Hosting
> > Placerville, CA  95667         edl@newmediaems.com 
> > (530) 622-9421                 http://www.newmediaems.com 
> > (866) 519-4680 Toll-Free       (530) 622-9426 Fax
> > ===============================================================
> > 
> > _______________________________________________
> > interchange-users mailing list
> > interchange-users@interchange.redhat.com 
> > http://interchange.redhat.com/mailman/listinfo/interchange-users 
> 
> -- 
> 
> Christopher F. Miller, Publisher                               cfm@maine.com 
> MaineStreet Communications, Inc           208 Portland Road, Gray, ME  04039
> 1.207.657.5078                                         http://www.maine.com/ 
> Content/site management, online commerce, internet integration, Debian linux
> _______________________________________________
> interchange-users mailing list
> interchange-users@interchange.redhat.com 
> http://interchange.redhat.com/mailman/listinfo/interchange-users

> BEGIN:VCARD
> VERSION:2.1
> X-GWTYPE:USER
> FN:Gary Norton
> EMAIL;WORK;PREF;NGW:GNORTON@broadgap.com
> N:Norton;Gary
> END:VCARD
> 


-- 

Christopher F. Miller, Publisher                               cfm@maine.com
MaineStreet Communications, Inc           208 Portland Road, Gray, ME  04039
1.207.657.5078                                         http://www.maine.com/
Content/site management, online commerce, internet integration, Debian linux