abombss <abombss_at_comcast.net> schrieb:
> 20+ joins are for all the attributes and legacy system codes
> associated with an address, mostly lookup tables. The easy solution
> would be to use the legacy system codes as primary keys and foreign
> keys to avoid frivolous joins, but we are trying to stay away from
> that, the volatility of the codes is forcing us to use surrogate keys
> instead.
If these are legacy systems, then how are the codes volatile? This
sounds almost like premature normalization -- if the codes are really
candidate keys, then why not use them as keys? A smart database would
"compress" them into a hash table anyways.
Received on Fri Jan 09 2004 - 13:17:56 CST
