データベースの自己結合を強制する方法（またはより良い方法はありますか）

Question

データベースに従業員テーブルがあり、従業員を上司にリンクしたい：

従業員表

• employee_id
• first_name
• last_name
• manager_id

manager_idが、マネージャーが従業員として持っている同じテーブル内の別の行である場合、従業員を削除した場合、この従業員が別の従業員のマネージャーではないことを検証する最善の方法は何ですか？

このためのベストプラクティスはありますか？

Answer 1

PK ＆amp;を使用して他のテーブルに参加するのと同じように、自己結合を使用できます。 FK 。

考慮すべきいくつかの点を考慮してこれを設計する必要があると思います。例：

• 異なるマネージャー：トムは今日Jr. Pgmrであり、ジェリーは今日のマネージャーです。明日トムはセバスチャンに報告するかもしれません。
• プロモーション：トムは今日Jr. Pgmrであり、ジェリーは彼のマネージャーです。明日、トムは自分でマネージャーになって、彼に報告する人がいるかもしれません。
• プロモーション2：トムはJr PgmrからSr Pgmr、チームリード、プロジェクトリード、マネージャーに行くことができます。これを保存しますか？
• レポート：ある時点で階層を表示したい場合があります（遅かれ早かれレポートを要求するユーザーもいます）

データを個別のエンティティに分割することを検討する必要がある場合があります-データを次のように正規化します（必要に応じてさらに）

• 従業員表：基本的な従業員情報
• ポジションルックアップテーブル：組織内のすべてのポジションのリスト
• 従業員の職位表：従業員の役職が変更された開始日と終了日を追跡します。
• 従業員ポジション階層テーブル：従業員ポジションが別の従業員ポジションに報告するもの（自己結合の代わりに二重結合を使用）。開始および終了タイムスタンプ付き

Answer 2

外部キー制約を使用できます（カスケード削除なし）。まだ他の従業員がいるマネージャーを削除しようとすると、データベースはそれを自動的に検出し、操作は失敗します。

Answer 3

アプリケーション（または組織）が進化した場合は、多対多の関連付けを使用してベースをカバーします。

Employee.Employee_id  <- EmployeeManager.Employee_id 
                         EmployeeManager.Manager_id -> Employee.Employee_id
                         Manager_role_type
                         etc.

常に外部キー制約を使用します。

Answer 4

外部キーを使用します。これは「通常の」です。これへのアプローチ：