Good point Steve, and it is a step that I will take if I can't do this any other way but by having separate tables. It is certainly more efficient that way anyway, and I have resigned my self to the realisation that even if their UNIX based system doesn't have the product database organised in separate tables, I will develop the processes so I can quickly add new future product ranges, and enable them to manage them via an admin system.
It's not that large a database of products anyway. Garth At 07:29 12/08/02 -0400, you wrote: >I might be able to take this one step further. I've worked with several >software packages for apparel retailers (referred to as 'soft-goods') on >both sides of the table, as an end-user and also with various developers. >For those that aren't aware, there are a number of differences between >systems for them vs. a traditional retailer (referred to as 'hard-goods'). >One of the biggest is the colour-size grid that Len refers to. > >With most systems, the grid is handled by multiple related tables. Some >systems will have separate tables for size, colour and in some cases >secondary size (i.e. men's shirts which need collar size and sleeve length). >The item numbering was handled in a method similar to what Len mentions, a >set of characters which identifies the main product, followed by extensions >which identify the size and/or colour of the specific item. > >In the XXX-YYY-ZZZ example, the XXX would come from the product table, the >YYY would come from the size table, and ZZZ from the colour table. > >One other thing that I remember was a difficulty in getting electronic data >out of these systems. Most vendors of these systems didn't understand the >idea of exporting data for use in other systems because the request rarely >came, most end-users didn't want/need to have the data exported. In some >cases when the ability was there, a multi-table system simply exported the >data in one big flat-file export. > >Perhaps you might try to get in touch with the vendor of the system your >client is using to see if there are other ways to have the data exported. It >might be that they have combined related tables into one export file simply >because that's all that anyone has ever asked for in the past. > >Hope this helps, > >Steve Smith > >Skadt Information Solutions >Office: (519) 624-4388 >GTA: (416) 606-3885 >Fax: (519) 624-3353 >Cell: (416) 606-3885 >Email: [EMAIL PROTECTED] >Web: http://www.skadt.com > > >-----Original Message----- >From: [EMAIL PROTECTED] >[mailto:[EMAIL PROTECTED]]On Behalf Of Len Wright >Sent: August 8, 2002 9:30 AM >To: Multiple recipients of list witango-talk >Subject: Re: Witango-Talk: Selective Arrays > > >I have worked with apparel manufacturers in the past that refer to your item >style as a color-size-style grid. > >Each occurance of the color, size, or style of an item requires a separate >item number, but the group of items are then transposed to show them as a >grid with each style displayed in a row, and each occurance of the color and >size displayed as a column. > >To achieve this, you will need a segmented item number such as XXX-YYY-ZZZ > >Where XXX is the style, YYY is the size, ZZZ is the color. > >hope this helps > >Regards, > >Len Wright >Plus International Corp >www.plusinternational.com > > >----- Original Message ----- >From: "Garth Penglase" <[EMAIL PROTECTED]> >To: "Multiple recipients of list witango-talk" <[EMAIL PROTECTED]> >Sent: Wednesday, August 07, 2002 7:39 AM >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 ________________________________________________________________________ TO UNSUBSCRIBE: send a plain text/US ASCII email to [EMAIL PROTECTED] with unsubscribe witango-talk in the message body
