At 11:05 PM -0700 4/1/01, Karl Simanonok wrote:
>Hi Dick,
>
>Thanks for your advice. That's a very pretty site at stbtrucks.com
>(excellent job on the graphics), but coding the back end in Perl must have
>been a major challenge, I would think. You must have used text files to
>store the data, instead of using a database, right?
I did use text files... this particular Perl subset had no database,
nor did it support lists or hashes (structures)
>I'm trying to get a
>handle on how to best design a relational database to handle any kind of
>car part or accessory, have you got any suggestions about that? If you
>could describe or even just list the columns in your data files (which for
>Perl is really just a way to manage data in a pseudo-database, right?) that
>might help a lot.
I need to be careful here, because the system is proprietary.
You would probably have main tables for:
Manufacturer
Category/Subcategory
Make/Model/Submodel/Year/Subyear
Manufacturer Product *
Manufacturer Product Options *
Application **
* Product and product options get a little tricky the options can
determine or affect the product code and the price, e.g.:
nnn-XX-YYY-nnn where XX denotes the finish and YYY denotes the size, etc.
Now consider that each finish/size combination may have a different price,
and, yet a third option may add to that price (stake pocket cutouts in bed
rail caps)
** Application (where used) is the key table it denotes where a
specific product can be used (which Make/Model/Submodel/Year/Subyear
of vehicle). I think we averaged about 3.5 applications per product.
I don't know if having a separate color table makes sense... here is
no standard usage among mfgrs.... one calls it teal, another calls it
blue or green...
Also, you may need to consider a denormalized database to efficiently
handle some of the more unusual data relationships.
A parting thought... Each year, many (but not all) of the
applications will need to be updated to include the new model year.
Another... Just building the Make/Model/Submodel/Year/Subyear table
is a major accomplishment.
HTH
Dick
>
>I'm thinking that Bud Schneehagen's suggestion of a flag field (or several)
>in the Products table that indicates what other (out of who knows how many
>there might ultimately be) tables to look in for supplementary data is
>probably what I'll wind up having to do. But that seems like a slightly
>kludgy way to do things, something tells me there has to be a better way...
>
>Regards,
>
>Karl S.
>
>
>Archives: http://www.mail-archive.com/cf-talk@houseoffusion.com/
>Unsubscribe: http://www.houseoffusion.com/index.cfm?sidebar=lists
Archives: http://www.mail-archive.com/cf-talk@houseoffusion.com/
Unsubscribe: http://www.houseoffusion.com/index.cfm?sidebar=lists
