データの構造が似ているからといって、同じ意味や同じ制約があるとは限りません。ルックアップ テーブルを別にしてください。これにより、外部キーが保持されます 分離して、データベースが間違った種類の検索データを参照するのを防ぐことができます。
親テーブルで基本構造を定義し、子テーブルに特定の FK を追加するだけで、リレーショナル DBMS が継承をサポートすることを望みます。現状では、DDL での繰り返しに耐える必要があります...
注:「ルックアップ テーブルを個別に保持する」ルールの 1 つの例外は、システムを動的にする必要がある場合 (つまり、データベースに新しい物理テーブルを実際に作成せずに新しい種類のルックアップ データを追加できる場合) かもしれませんが、そうは見えません。
1 つの大きなルックアップ テーブルでは、FK だけでは停止しません (たとえば) ShippingLog テーブルが EmployeeTask 用の行を参照しないようにする テーブル。関係の識別と PK の移行を使用することで、この問題から身を守ることができますが、冗長性を導入したり、慎重な制約を加えたりする必要があります。単純に正しいことを行い、ルックアップ テーブルを分離しておく方が、クリーンでおそらくパフォーマンスが向上します。