Alan McDonald wrote:

>
> We used not to be able to have FKs with duplicate NULLs. Now we can. this
> leads to table structures being able to consolidate data from several
> sources leaving certain FKs null while the critical one for this
> relationship is filled. e.g. lets imagine a contacts list for 3 separate
> tables, client, contractors and suppliers.

I'm not sure I understand the design, but is sounds like bad
normalization ... Consolidation is rarely a good thing in relational
theory.

> One contact table with 3 FKs into
> the three master tables. For each relation, the other two FKs remain null
> while the one FK is the key to the relation in question.
> Now this obviously leads to high dups on the FK index.

I'm probably confused by your use of "relation" - which to me equates to
table, and seems to mean something else you.

> What's good/bad/indifferent about this design?

Pragmatically,what's bad is that garbage collection after a delete is
going to be really slow until you get Version 2. Theoretically, I've
got doubts about the normalization.


Regards,


Ann