> Lets say a table had a column called price defined as N(11, 4
> ) Now it is
> found that the number of different prices is much less then 10^11, but
> something more like 10,000 ( Or more specifically much less
> then the limit
> of VFPs integer's type ). Because this column has repeated
> values that are
> not a foreign key is not following good normalization ( OK OK
> note the title
> Fanatical Normalization ). Therefore the column could be
> changed to use an
> integer F-Key to a lookup table of prices, and the bonus is
> that the column would be using 4/11 of the space it did before.
A price column is a simple value-- not a reference to a fixed list of anything. Theoretically, it could be considered a link to an implicit table with PKs of 0-99999.9999. Maintaining a "Prices" table of a subset of this implicit table(just the prices in your main product table) would involve a lot of management, and be prone to problems. I believe this is an over-use, and even an abuse of 'normalization'. I wouldn't even consider it normalization. The only reason I can see for a price table, is if you have different levels of pricing-- say quantity based discounts, time-of-day based discounts, etc.
--
Derek
©2004 Derek J. Kalweit |
