お恥ずかしい話ですが、最近、相互に関連する 3 つの異なるタイプの銀行エンティティに対して 1 つのテーブルを作成する必要がある状況がありました。説明させてください。
統治銀行、地方の支店を運営する通常の銀行、またはこの銀行の下で運営されている地方の支店、またはこの階層には属さないが地方の支店とのみ取引するリテール銀行の支店の詳細を保持する BANK テーブルを想像してみてください。
以前は、FK 制約 (管理銀行、地方支店を運営する銀行、地方支店、リテール銀行支店にそれぞれ 1 つずつ) を使用して、これらに 4 つの異なるテーブルを用意することにしました。しかし、TRANSACTION テーブルの作成に移ったとき、これらのエンティティのいずれかの間でトランザクションが発生する可能性があるため (例: 地方の支店と小売店の間、地方の支店同士など)、当惑しました。これは、銀行エンティティの「ソース」と「宛先」ID の記録を保持するだけでなく、アプリケーション ロジックがクエリのためにどのテーブルに結合するかを決定するのに役立ついくつかのデータを保持する必要があることを意味しました。悪い。
さらに、USER テーブルがあり、ユーザーはこれらのエンティティのいずれかに属している可能性があります。ここでも、銀行エンティティの 4 つの異なるテーブルがあると問題がありました。ユーザーが地方の支店、小売店、または管理銀行に属しているかどうかはどうすればわかりますか?
したがって、単一の BANK テーブルを作成しました (基本的に、これらは互いに取引できるため、類似したエンティティであるためです)。親機関の ID の値を保持する PARENT 列をテーブルに追加しました (別の方法で FK を使用して達成した関係)。したがって、地方の支店は、親列に営業銀行の ID を持ちます。小売店の支店には親がないため、値は NULL です。
私が今見ている問題は、循環参照である BANK テーブルに PK/FK 関係があることです。
私の質問は次のとおりです。これはどれほど悪いですか？そして、何が抜け道になるでしょうか？