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
