Our version of that isn't so much a price table. It uses a "linker"
table to produce the many-to-many relationships between people,
addresses, phone numbers, individual locations, and parent companies.
Each record in the "linker" table is two related key values.
Fortunately for me, the management was written into the app when I got
here. When new data is entered, the app checks the existing table for
that type of data. If it's there already, the app stores the key to it.
If it's not there, it gets added to the pertinent table and a new key
is generated. It took me awhile, but after having wrapped my head
around it, I can use the underlying tables to create the ad hoc views
that were not thought of originally.
Ray <><
>>> dkalweit .at. sensiblesoftware D.OT com 4/30/2004 2:47:22 PM >>>
> 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
[excessive quoting removed by server]
©2004 Ray Heilman |
