This is different. What if I have two parent tables to an Addresses table; say Clients and Suppliers?

So the Addresses table would have an fkClient and an fkSupplier...

>If each child definitely has 2 parents then I see no difference between this and, say, somebody having 2 addresses - home address, work address, say (on a mega-normalised dbc where the addresses are kept in a separate table). If not then you have redundancy.
>
>In the latter case, and especially where a parent can be parent to >1 child, you'd want a BOM 1-m-1 relationship
>

>PARENT
>pkParent
>   |
>PARENTCHILD
>fkParent
>fkChild
>   |
>CHILD
>pkChild
>

>Then a parent can have as many children as they want and vice-versa
>
>HTH
>
>Terry
>
>
>>I have a situation where I have a child table that will be a child to two different parent tables. It's kind of like this:
>>
>>

>>
>>PARENT 1     PARENT 2
>>pkParent1    pkParent2
>>   |            |
>>   --------------
>>          |
>>        CHILD
>>        pkChild
>>        fkParent1
>>        fkParent2
>>
>>

>>
>>My question is...Is this good design? Is it commly acceptable to have a child with two foreign keys pointing to differnt parent tables when one or the other fk value will be null?