Wrox Book FeedbackA forum to submit feedback on Wrox books if other forums on P2P have been unable to address your book-specific needs. IF YOU ARE LOOKING FOR CODE DO NOT ASK "Where can I find the code for this book?"That question is answered here.
Welcome to the p2p.wrox.com Forums.
You are currently viewing the Wrox Book Feedback section of the Wrox Programmer to Programmer discussions. This is a community of tens of thousands of software programmers and website developers including Wrox book authors and readers. As a guest, you can read any forum posting. By joining today you can post your own programming questions, respond to other developers’ questions, and eliminate the ads that are displayed to guests. Registration is fast, simple and absolutely free .
There is an error on chapter 8 pg.228-229 of "Professional SQL Server 2000 Programming". The Third Normal Form explicitly states that no column can have any dependency on any other non-key column. Yet, the author chose to leave UnitPrice in the OrderDetails Table. UnitPrice obviously depends on PartNo, and should be located in the PartNo Table. What do you guys think?
I don't have the book, and I don't know the scenario or requirements that resulted in the final design, but IMO a UnitPrice may be better of in an OrderDetails table than in a PartNo.
When you buy an item, it has a specific price at that very moment. It's that price that you want to maintain in your system for ever for that specific order and product, so it's added to the OrderDetails table rather than to the PartNo table.
Suppose you buy 10 items of product x for $1. After a while, the price is increased to $1,10. Now, looking at the history of the system, did you all of a sudden pay $11.00 for your 10 products? No, you didn't. You still paid $10.
If you'd maintained the price in the PartNo table, the price would also have changed for every historical order, something that you really really don't want in your system.
Does this make sense?
Everyone is unique, except for me.
I would argue that the price is dependent on the Order - rather than the part number. From the POV of the order price- the price depends on the order itself. As a second order at another time could have another price.
I guess this could also be done by normalizing out the prices and create a pricing table that is effective dated and related to the part.
The second way is probably "more proper".. but I think you can over-normalize things aso. And based on the requirements for the system, there might not be value in normalizing out the pricing.
Thanks guys. You both make extremely good points. My initial assumption is definitely not useful for maintaining an Order history. :D My conclusion is that the UnitPrice is dependent on two variables: PartNo and time. Hal's second approach would probably attack that issue best, because otherwise you'd have to always have a hardcopy of recent prices around. I guess it's a trade off between how much of the data you are willing to utilize in hardcopy format vs. database format.