Thanks for your reply Kristen.
I'm not sure i fully understand you as the first part refers to ignoring FK restriction and creating of trigger.
Both seem wrong to me (in case i understood you correctly...) as SQL DRI must remain and trigger seems too heavy for my scenario.
Second part refers to linking table (which seems as a good solution) but why i need several child.
Please allow me to explain my scenario better.
i have 5 tables (A, B, C, D and E with no correlation between them) that should save photos. each record in each table can save 1 or many photos. what i wanted to achieve is to have one table (BlobFile) that stores all the paths of the photos. so it seems reasonable that BlobFile will contain one column with the primary key of each source table (A, B, C, D and E).
A OneToMany BlobFile
B OneToMany BlobFile
C OneToMany BlobFile
But, SQL can't have one FK column that stores primary key of different tables. so it creates FK column in BlobFile for each source table, A_FK, B_FK, C_FK, Etc...
What i had in mind is to create a linking table, as follows:
A OneToOne LinkingTable OneToMany BlobFile
B OneToOne LinkingTable OneToMany BlobFile
Is this seems as a good solution?