Thanks for the input Robert, comments below... At 06:45 8/08/02 -0700, you wrote: >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)
Well, after segmenting the product database into separate tables to get the search functionality and indexing I require, it shouldn't be too large, however we are talking of a product list which includes approx. 5000 product codes, names, and prices as well as 4 indexed id columns relating to the other tables. I haven't had that much experience with determining how much memory is needed per user for such a table if it is pulled into an array in memory. >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. Well, that is the solution that I thought I was going to have to use in the furst place, and really what I am trying to avoid, since this requires manually separating these lists of products which form a product range and colour-grid, into a separate table. I can always do that, but it means that there is extra work required for ongoing maintenance of the product database. >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 ________________________________________________________________________ TO UNSUBSCRIBE: send a plain text/US ASCII email to [EMAIL PROTECTED] with unsubscribe witango-talk in the message body
