Re: Unique Constraint with Multiple NULLS
From: Adrian Kubala <adrian_at_sixfingeredman.net>
Date: Fri, 9 Jan 2004 13:17:56 -0600
Message-ID: <slrnbvtvj4.ano.adrian_at_sixfingeredman.net>
Date: Fri, 9 Jan 2004 13:17:56 -0600
Message-ID: <slrnbvtvj4.ano.adrian_at_sixfingeredman.net>
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 - 20:17:56 CET