I'd recommend going for the normalized tables first. You can optimize it, if there is a need, later on. You'd be better off sticking with a conservative and _correct_ database design with no funny stuff (i.e. denormalization). Remember, it's important to make sure you have a good design for your database. Everything else flows out from that, and it's a real pain to have to go back and re-code. I've had (by far) better luck starting out with a properly normalized schema and then denormailzing it, but only if I really need to. If you are worried about performance, you'd be better off making sure you have a faster (separate) machine to run the db on.
With a normalized table, you won't need to worry about junk data. And it'll be easier to maintain your database after you leave. When the marketing people come asking for reports, you'll be able to provide them more effectively. And when you need to add more features to your system, you'll be able to without going through huge amounts of unnecessary pain. Just my $0.02... Jeff Polaski Manager, Web Services Research & Graduate Studies University California, Irvine -----Original Message----- From: Dunwiddie, Bruce [mailto:[EMAIL PROTECTED]] Sent: Friday, December 07, 2001 8:44 AM To: CF-Talk Subject: RE: What the best database structure to do this? you should be able to cache the query for stuff like that, so as long as you do, you shouldn't have to worry about it. -----Original Message----- From: Jon Hall [mailto:[EMAIL PROTECTED]] Sent: Thursday, December 06, 2001 7:37 PM To: CF-Talk Subject: What the best database structure to do this? 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/[email protected]/ Unsubscribe: http://www.houseoffusion.com/index.cfm?sidebar=lists
