Ce n'est pas parce que les données ont une structure similaire qu'elles ont la même signification ou les mêmes contraintes. Gardez vos tables de recherche séparées. Cela conserve les clés étrangères séparé, afin que la base de données puisse se protéger contre le référencement du mauvais type de données de recherche.
Je souhaite que les SGBD relationnels prennent en charge l'héritage, où vous pouvez définir la structure de base dans la table parent et simplement ajouter des FK spécifiques dans les tables enfants. Dans l'état actuel des choses, vous devrez endurer quelques répétitions dans votre DDL...
REMARQUE :Une exception à la règle "garder les tables de recherche séparées" peut être lorsque votre système doit être dynamique (c'est-à-dire être capable d'ajouter de nouveaux types de données de recherche sans réellement créer de nouvelles tables physiques dans la base de données), mais il ne semble pas que loin de votre question.
Avec une grande table de recherche, les FK seuls n'arrêteront pas (par exemple) le ShippingLog table de référencer une ligne destinée à la EmployeeTask table. En utilisant des relations d'identification et en migrant des PK, vous pouvez vous en protéger, mais non sans introduire des redondances et nécessiter des contraintes prudentes. C'est plus propre et probablement plus performant de simplement faire ce qu'il faut et de séparer les tables de recherche.
