I don't know if this would help, but I have done this for a couple of clients, both of which had database structures that I could not alter, and product codes that did not help. The method I am suggesting assumes that the product database is far too large to maintain in memory for all users in the domain or application scope. (This would save a lot of hits to the DBMS)
If you create a new table, like your header table, that just contained the information that is common to a group, like the image and price, gen description, and a text field where you could place delimited sku's. Then you would initially just search on your new table. When you need to show detail on a sku, you could build a DBMS action from your delimited skus to populate your table. Even better you could create a tcf that would accept as its input an array of sku's, then send out an array of each skus color and whatever. This would allow you to use the <@callmethod> action within the results of your initial search action, or even within a tml. If your dbms is fast and uses a good cacheing mechanism, this will work very fast. Robert. On Thursday, August 8, 2002, at 05:47 AM, Garth Penglase wrote: > Sounds like this could work. > > At the moment I have a heading table which contains common headings > for each product range, so i could probably use the heading id number > in product list to build <@DISTINCT> arrays. I'll have to investigate > this further to see if it upsets some of the structure that I am > currently using - due to the multiple levels of headings and groupings > it is reasonably convoluted. > > Also, as I have multiple ranges in any given search, I guess I would > have to use a Direct DBMS action to create the necessary SQL to do > this. However I am concerned that in a product list of 5000 items I > might run into time delays? > > IMAGE NAMES problem > At present I am considering how to organise the image names. Currently > the expectation is to have them all named after the product code of > the item, which works fine for the single items, but when it comes to > a group of items in which the only difference is the colour, there > will be only one image. > > The determining factor in this is that the shopper expects to be > looking at the same image, no matter whether he pulls up a single item > in the range (through a specific search) or whether he drills down by > brand or product type and gets the whole product range displayed as a > image, heading, text and colour-grid. > > Garth > > > At 09:32 8/08/02 -0400, you wrote: >> If you have a key that's common for a group of products (maybe the >> filename >> of the image?), you can build a <@DISTINCT> array based on this >> column -- >> then loop through this array, each time doing an <@FILTER> comparing >> the >> curent image filename to the original database and building an array >> from >> your <@FILTER> result. >> >> So each iteration through the DISTINCT you'll generate an array of >> products >> that belong to the same image. >> >> - James >> >> >> -----Original Message----- >> From: [EMAIL PROTECTED] >> [mailto:[EMAIL PROTECTED]]On Behalf Of Garth Penglase >> Sent: Wednesday, August 07, 2002 10:40 AM >> To: Multiple recipients of list witango-talk >> Subject: Witango-Talk: Selective Arrays >> >> >> Hi all, maybe you can help me with this... >> >> I have a large (reasonably complex) product database. Each product >> has a >> alpha-numeric code and a unique ID and other product related things >> like >> price, a flag for whether it is being discounted etc. A lot of the >> products >> are simply one item, one price and displayed with one graphic. See >> example >> at http://netramp.com.au/hhb/indola.jpg >> >> While all of these products are singular items and each has a price, >> some >> of them (not all of them) are simply different shades of the same >> product, >> and therefore there is only one graphic for the "main product" and in >> the >> catalogue only one entry is displayed with a table for the colours. ie >> >> Wella Fresh Colour Liquid 3/0 Dark Brown >> Wella Fresh Colour Liquid 5/0 Light Brown >> Wella Fresh Colour Liquid 7/0 Medium Blonde >> Wella Fresh Colour Liquid 8/0 Light Blonde >> Wella Fresh Colour Liquid 5/66 Bordeaux >> Wella Fresh Colour Liquid 6/4 Mahogany >> >> etc. (some have as many as 150 different colour/shades/combinations) >> >> The problem is that I want to separate these types of products out and >> create an array for each which is then displayed as a table of colour >> options (click on link above to see example), listed directly below >> the >> main product image and header (thankfully, I have separate headings >> which >> appear for product ranges - though these have also been manually >> added to >> the database for each product range). >> >> In the past I had a manual process to create this for other sites, >> which >> created separate external html files which were <@INCLUDE>ed whenever >> the >> product range was called upon BUT now it is different, in that: >> - the Internet product database is updated quarterly (in conjunction >> with >> their magazine) and has constant changes to the product line >> - Their internal systems are archaic and therefore at this juncture I >> cannot get them to provide me with anything out of their product >> database >> but a single flat file with all products each quarter, and maybe a >> 'changed >> products' list (the maintenance issue of synchronising these two >> databases >> is a doozy let me say, and that's a another issue which I'll have to >> be >> creative with as well). >> >> My initial thought was to separate these product ranges out of the >> main >> product database, leave one product range header item in the database >> which, via a flag, when selected calls up a separate table of the >> range >> colours which I then display as an array in tabular format. However, >> due to >> the number of instances of this in the database, I can't see how it >> would >> be feasible to do this each quarter. >> >> Does anyone have any idea of how I can, on a search where any of these >> items comes up, force it to separate these items out into a separate >> array >> for each instance of a product range like this being found/requested? >> >> thanks in advance for any ideas - I am hoping that I don't have to >> searpate >> these product items out into a separate table, but I can't see a >> clean or >> simple way of avoiding it. >> Garth >> >> >> ______________________________________________________________________ >> __ >> TO UNSUBSCRIBE: send a plain text/US ASCII email to >> [EMAIL PROTECTED] >> with unsubscribe witango-talk in the message body >> >> ______________________________________________________________________ >> __ >> TO UNSUBSCRIBE: send a plain text/US ASCII email to >> [EMAIL PROTECTED] >> with unsubscribe witango-talk in the message body > > _______________________________________________________________________ > _ > TO UNSUBSCRIBE: send a plain text/US ASCII email to > [EMAIL PROTECTED] > with unsubscribe witango-talk in the message body > -- Robert Garcia BigHead Technology 2781 N Carlmont Pl Simi Valley, CA 93065 Phone 805.501.1390 Fax 805.522.8557 http://www.bighead.net/ [EMAIL PROTECTED] ________________________________________________________________________ TO UNSUBSCRIBE: send a plain text/US ASCII email to [EMAIL PROTECTED] with unsubscribe witango-talk in the message body
