1

わかりましたので、これが私が直面している問題です。私はスキーマの完全な再設計を受け入れていますが、基本的には正しい軌道に乗っていると思います。

表 1 - インストラクター

- ID - (Auto increment int)
 - Name
 - employee ID
 - ADDITIONAL COLUMNS NOT IMPORTANT TO THIS QUESTION
 - account_id --> FK relation to (Accounts)

表 2 - 学生

- ID - (Auto increment int)
 - Name
 - student ID
 - ADDITIONAL COLUMNS NOT IMPORTANT TO THIS QUESTION
 - account_id --> FK relation to (Accounts)

表 3 - アカウント

- ID - (Auto increment int)
 - USERNAME
 - PASSWORD
 - TYPE (Instructor OR Student)
 - person_id --> FK relation to (Students(ID)) & (Instructors(ID))

だから、私のロジックは現在どのように流れているかは次のようになります

  1. 人物を挿入 (学生またはインストラクター)
  2. TRIGGER INSERTS は名前に基づいてアカウントを挿入します
  3. TRIGGER UPDATES 受講者または講師のレコードを account_id で更新します

この問題は、mysql が再帰的なトリガーを許可しないために発生します。

しかし、更新を受け取ったときに何かをするのを待っているトリガーがないため、トリガーを介してテーブル1を更新することに問題がある理由がわかりません。

システムをこのように機能させたい理由は、インストラクターと学生の両方に 1 つの中央ログインがあり、各テーブルに対して 1 つずつ 2 つの mysql 呼び出しを実行できることをよく知っているためです。アカウント テーブル。

個人テーブル (インストラクター/学生) からアカウント テーブルへの関係が必要な理由は、インストラクターまたは学生を削除すると、それに付随するアカウントも削除されるためです。

前もって感謝します!

4

0 に答える 0