> I've been wrestling with this for the last half hour and I can not decide > the best way to structure the database for a function I a programming > related to a shopping cart. It get's kind of crazy...
This was a nightmare question that we almost had to deal with at my last job. Throw this into the mix... you have (say) t-shirts. You can get S, M, L, XL in colours, red, green and blue. But you can't get small in blue. Nor large in green. How can a fully normalised structure account for this? Plus you're bound to find that one day for some new products sizes and colours aren't applicable. Do you have one table for clothing items (if you can find a way of accounting for the situations given above) and a new table for every new product type? My eventual suggestion was to denormalise the products table (in the end, the company shifted focus and we didn't get to build that product so the theory wasn't tested.). OK, you can't increase the base price for a product in one go, but it does give you a much more granular level of control. Plus, if you need to make lots of changes, you can always write an SQL script to perform a large product update in one go, depending on the situation. -- Aidan Whitehall <[EMAIL PROTECTED]> Macromedia ColdFusion Developer Fairbanks Environmental +44 (0)1695 51775 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Get the mailserver that powers this list at http://www.coolfusion.com FAQ: http://www.thenetprofits.co.uk/coldfusion/faq Archives: http://www.mail-archive.com/[email protected]/ Unsubscribe: http://www.houseoffusion.com/index.cfm?sidebar=lists
