クライアントがカテゴリ、サブカテゴリ、サブサブカテゴリなどを必要とするデータベースがある場合、それを行うための最良の方法は何ですか？必要なのが3つだけで、3つ必要だと常にわかっていれば、cat、subcat、subsubcatなどの3つのテーブルを作成できます。しかし、彼らがさらに深みを求めている場合はどうでしょうか？私は3つのテーブルが好きではありませんが、それが私がそれを行う方法を知っている唯一の方法です。
「 SQL隣接リスト」を見たことがありますが、それが唯一の方法かどうかはわかりませんでした。クライアントが任意のレベルのカテゴリとサブカテゴリを持つことができるように、私は入力を望んでいました。これは階層データを意味すると思います。
編集：可能であればSQLがリストを取り戻すことを望んでいました
ありがとうございました。
table categories: id, title, parent_category_id
id | title | parent_category_id
----+-------+-------------------
1 | food | NULL
2 | pizza | 1
3 | wines | NULL
4 | red | 3
5 | white | 3
6 | bread | 1
私は通常select *、アプリケーション層でアルゴリズムを実行してツリーをアセンブルします。
あなたはジョー・セルコの本、またはこの前の質問を見るかもしれません。
それ自体との関係を持つテーブルを作成することは、同じことを行うための最良の方法です。制限なく、必要な範囲で簡単かつ柔軟に使用できます。最初の答えですでに提案されているので、私はあなたが置くべき構造を繰り返す必要はないと思います。
"id, parent_id"私はいくつかの方法で作業しましたが、ルートアイテムが持つ単純なテーブル内の関係に固執していparent_id=0ます。ツリー内のアイテムを頻繁にクエリする必要がある場合、特に「ブランチ」または1つのノードの基礎となるすべての要素のみが必要な場合は、2番目のテーブルを使用できます。各ノードのアップパスで各ノードへ"id, path_id, level"の参照を保持します。 。これは大量のデータのように見えるかもしれませんが、使用するとブランチルックアップが大幅に改善され、トリガーでレンダリングするのは非常に管理しやすくなります。