Question

If a DB is designed as:

Table A a (type x) a is (PK)  Table B a (type x) a is (PK)  Table C a (type x) a is (FK) references A(a) a is (FK) references B(a) 

Is this correct design? If not, what’s the best design for this case?

Answer 1

I believe the situation you are referring to is where C could be a child of A or B.

for example

if A is pages

B is pictures

and C is comments

C could be a comment for a picture or a comment for a page.

in this case I would adjust C to be a dual key as follows

Table C: a (type x) b (type CHAR) //<- defines which table a is the key of INDEX(b,a)  SQL = SELECT * from C where b = TABLE_A_name and C.a = A.a  or SQL = SELECT * from C where b = TABLE_B_name AND C.a = B.a  

You’ll then have to impliment data integrity from the application side.

So it’s fuzzy design in terms of foreign key implementation and data integrity. The question is if the application functionality is worth the chaos and if it will be in a well managed environment.