design confusion
Posted: Fri Jan 23, 2004 4:07 pm
I'm having a brain meltdown trying to design a database structure for an application I'm building. Basically, it's a complaint system. Users can enter a complaint for an item on any of about 10 different categories. Now, I've come up with the design for the interface and the IA, and that all makes good sense. But coming down to the DB implementation, it's confusing.
For instance, one of the ways in which a user can comment is to change the price on an item. But an item actually has *3* different prices (a List price, a Hidden price, and a Display price), and might have more or less in the future. It needs to be possible for a user to complain on more than one of those prices at a time... so for instance: "Change List Price from $200 to $150" and also "Change Display Price from $130 to $100." So, okay, I could just build 3 redundant structures into the table, one for each pricing type, but that's a clunky solution considering that the number or names of the pricing systems could change in the future. I want this thing to be seamlessly extensible.
Do you see what I'm getting at?
For instance, one of the ways in which a user can comment is to change the price on an item. But an item actually has *3* different prices (a List price, a Hidden price, and a Display price), and might have more or less in the future. It needs to be possible for a user to complain on more than one of those prices at a time... so for instance: "Change List Price from $200 to $150" and also "Change Display Price from $130 to $100." So, okay, I could just build 3 redundant structures into the table, one for each pricing type, but that's a clunky solution considering that the number or names of the pricing systems could change in the future. I want this thing to be seamlessly extensible.
Do you see what I'm getting at?