データベース設計に戻りましたが、知識に大きなギャップがあることに気づきました。
カテゴリを含むテーブルがあります。各カテゴリには多くのサブカテゴリを含めることができ、各サブカテゴリは多くのスーパーカテゴリに属することができます。
すべてのサブカテゴリフォルダを含むカテゴリ名のフォルダを作成したいと思います。（Windowsフォルダのようなビジュアルオブジェクト）したがって、サブカテゴリのクイック検索を実行する必要があります。
この場合、1：MまたはM：Nの関係を使用する利点は何ですか？そして、各デザインをどのように実装するのですか？
1：Mの単項関係であるERDモデルを作成しました。（この図には、すべての経費値を格納する経費テーブルも含まれていますが、この場合は関係ありません）
このデザインは正しいですか？
多対多の単項関係により、スーパーカテゴリの検索が高速化され、デフォルトで最適な設計になりますか？
ERDを含む回答を希望します
私があなたを正しく理解していれば、1つのサブカテゴリに最大で1つの（直接の）スーパーカテゴリを含めることができます。その場合、個別のテーブルは必要ありません。このようなもので十分です：
明らかに、すべてのレベルからサブカテゴリを取得するには再帰クエリが必要ですが、PARENT_IDにインデックスを付けると、かなり効率的になるはずです。
反対方向に進む（そしてすべての祖先を取得する）には、再帰クエリも必要になります。これにはPK（自動的にインデックスが付けられる）での検索が必要になるため、これもかなり効率的です。
その他のアイデアとさまざまなパフォーマンスのトレードオフについては、このスライドショーをご覧ください。
場合によっては、リレーショナルデータベースでマルチレベル階層を維持する最も簡単な方法は、「修正されたプレオーダーツリートラバーサル」（MPTT）とも呼ばれる入れ子集合モデルです。
基本的に、ツリーノードには、親IDだけでなく、左端と右端のリーフのIDも格納されます。
spending_category
-----------------
parent_id int
left_id int
right_id int
name char
これを行うことの主な利点は、単一のクエリでノードのサブツリー全体を取得できることです。サブツリーノードのIDはleft_idとright_idの間にあります。多くのバリエーションがあります。その他は、親ノードIDに加えて、またはその代わりにノードの深さを格納します。
欠点は、ノードが挿入または削除されたときにleft_idとright_idを更新する必要があることです。つまり、このアプローチは中程度のサイズのツリーにのみ役立ちます。
ウィキペディアの記事とブランコが言及したスライドショーは、私ができるよりもテクニックをよく説明しています。リレーショナルデータベースに階層データを格納するさまざまな方法について詳しく知りたい場合は、このリソースのリストも確認してください。