Re: ANN: a portable data component -- length
Certainly it sometimes makes sense to provide "redundant" data in this way. But do you really (a) provide the values in multiple units, (b) provide the conversion factor, and (c) check the values for validity using the conversion factor, which is what is being proposed here? For example, if you're providing prices for both imperial and metric weights, the prices ought to be in integral units of currency/coinage that people actually carry (no hundredths of shillings), and the weights some values that people in grocery stores can actually measure, right? And do those numbers really work out so the exact same numbers appear on both sides of the conversion equations? On Apr 9, 2011, at 1:06 PM, Stephen D Green wrote: > Normal form isn't the only way to express data. It works for some > scenarios but decidely not for others; take analytical databases, data > marts, data warehouses, etc. For ages in the UK we had to have the > price of loose fruit and vegetables on our shop shelves expressed in > both price per imperial and price per metric weight. We still have > shoes and clothes sold in UK and EU sizes. We don't give people one > price and say "go work the other price out" or one size and say "go > work out the other size; here is the conversion factor"... So we often > produce price lists, I expect in XML, with multiple prices in mutliple > currencies and we design database table deliberately with redundant > information so that there is no need for extra time spent > dereferencing information held in separate tables. I think Roger's > examples hold well.
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index]
PURCHASE STYLUS STUDIO ONLINE TODAY!
Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced!
Download The World's Best XML IDE!
Accelerate XML development with our award-winning XML IDE - Download a free trial today!
Subscribe in XML format