Ann - clarify something else for me,

> > I had a high max dup on the tables cited in (3b), so I did a compound
> > index with the primary key. But I still have a high "total dup"?
>
> Gstat will report duplicates on unique indexes - that's one of the
> oddities of multi-generational indexes. No one transaction can see more
> than one instance of each value, but different transactions can see
> different instances. I wouldn't expect a lot of duplicates, but quite
> possibly a record is being deleted, then another with the same key value
> is created over and over ....
>
> > INDEX_Q
> > Average data length: 0.00, total dup: 2379, max dup: 28
> > INDEX_X
> > Average data length: 0.00, total dup: 29593, max dup: 32
>
> Average data length shows that prefix compression is working well, and
> that there's a high percentage of duplicate values. Neither of the max
> dup values are in the critical range.
>
> Hope this helps,
>
>
> Ann

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. 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.
What's good/bad/indifferent about this design?
Alan