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...
Each item can have a variable number of sizes. Each size can have a variable upcharge attached to it. Each item can have a variables number of price levels for different types of customers with variable quantity breaks per price level. All of the above is done. I am now trying to add in the sizes so that I can set variable size/quantity discounts at different price levels. If I totally normalize the new size table, given 500 products, 4 quantity breaks, 4 sizes and 2 pricing levels, I end up with 16000 rows, albeit in a very nicely indexable table. That's an extreme example for the probable use of the software, but I want to make sure it doesn't break under load either. I know 16000 rows is not a big deal for SQL Server, but since the data in the table will be used for displaying the item, I can see it getting hit pretty hard. Should I be worried about this table, or does anyone have any tips? RDBMS == SQL Server jon ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 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/cf-talk@houseoffusion.com/ Unsubscribe: http://www.houseoffusion.com/index.cfm?sidebar=lists
