問題の古典的な形は、従業員がいて、従業員にはマネージャーがいて、マネージャーが CEO でない限りマネージャーがいるというものだと思います。
では、どのようにデータを保存しますか？解決策 1: 従業員テーブルに manager_id を含めるか、employee_manager テーブルを含めることができるように思われます (そのようにして、多数のマネージャまたはゼロ マネージャを使用できます)。
SQL は再帰をサポートしておらず、従業員の上にいるすべてのマネージャーを検索するクエリがないため、解決策 1 は悪い考えだと言う人もいます。これらの人々は別のアイデアを持っています (従業員がマネージャーのリストを持っているなど) が、それらはすべて、維持するのが非常に難しい正規化されていないデータの混乱を含んでいるようです。
それで、皆さんはどう思いますか？
私は他の人に同意します..再帰が利用可能です。
manager_id を emp テーブルに配置しません (SCOTT/TIGER の古代の知恵にもかかわらず)。現実の世界では、このビジネス ルールが常に破られており、十分に正規化されていません。
代わりに、person_to_person タイプのリンク テーブルを考えてみましょう。このテーブルでは、2 人の人物が役割のある期間に相互に関連付けられます。たとえば、person1 は、1 月から 3 月までの person2 にマネージャーとして関連付けられます。これにより、ある時点で複数のマネージャーがいるという現実があっても、プロジェクト、部門、任意のグループに人を柔軟に割り当てることができます。
また、人と部門の関係は似ていることも考慮してください。人は、微妙な方法で同時に複数の部門に関連付けられる場合があります。
データの整合性制約を適用する場所と、クエリを実行する場所や興味深いことを行う場所を決定する必要があります。
他の人が述べたように、一部のデータベース サーバーは再帰クエリをサポートしていません。ただし、データベースにクエリを実行する場合は、コードでツリーを作成します。これは論点です。
しかし、SQL でそれができたとしても、本当にしたいのでしょうか? SQL はいくつかの場合には優れていますが、すべての場合に適しているわけではありません。
主な関心事は、データベースが得意なことを実行できるようにすることです。この場合は、ソリューション 1 のように聞こえます。
Oracleの構成のように、一部のデータベースには再帰クエリがありCONNECT BYます。その場合、私は確かに1を選びます。
しかし、そうでなくても、それが実際にデータの構造である場合、すべての人に自分のマネージャーを与えると、データはよりクリーンになると思います。すべてのマネージャーをCEOに任せるには、複数のクエリを実行する必要があります。または、すべてのデータを取得して、使用しているプログラミング言語でツリーを構築する必要があります。しかし、すべての人がマネージャーのリストを取得した場合、同じ問題が発生します。このデータからツリーを構築する場合は、プログラミングインテリジェンスが必要になります。Oracleを入手しない限り、それはそうです。;）
ちなみに、私は部門のリストを作成し、各部門にマネージャーを与えることを選択します。そうすれば、従業員を更新しなくても、人（マネージャーでさえ）を別の位置に簡単に配置できます。通常、マネージャーは部門を管理します。その部門で働くのは他の人のマネージャーだけです。