カテゴリをクリックすると、現在のカテゴリ内のすべての製品とそのすべてのサブカテゴリが一覧表示されます。

上記はカテゴリ テーブルです。製品テーブルは、製品が属するカテゴリを決定する、関連するカテゴリ テーブルの cate_id です

ここで、私が望む効果は、カテゴリをクリックして、カテゴリ内のすべての製品をリストすることです。現在のカテゴリとそのすべてのサブカテゴリ

アドバイスをください

再帰のことを考えて頭がクラクラしています。まだ？どうやってするの？

ディスカッションに返信 (解決策)

カテゴリをクリックすると、分類番号がわかります
データベースにクエリを実行すると、この分類番号を持つ親カテゴリ番号がそのサブカテゴリになります

カテゴリなので、分類番号を知っておくだけです
データベースをクエリします。親カテゴリ番号はこの分類番号であり、それはそのサブカテゴリです

サブカテゴリは必要ありません、サブカテゴリの下にあるすべての製品が必要ですカテゴリ

不思議です、サブカテゴリがあります。いいえ、サブカテゴリの下にある商品がまだ心配ですか?

データ量が大きいかどうかはわかりません
小規模ビジネスの Web サイトの場合、親カテゴリ ID を取得した後、すべてのサブカテゴリ ID を見つけて、それらを結合します: 2、5、6、7、8など。
次に、プロダクトテーブルに移動します。 in キーワードを使用して SQL ステートメントを見つけます。 使い方は? 検索してください...
in がインデックスを使用できるかどうかはわかりません。

データ量が比較的大きい場合は、効率を高めるために冗長性を使用します。
分類テーブルにフロア フィールドを追加し、親カテゴリに 0、第 1 レベルのサブカテゴリに 1、第 2 レベルのサブカテゴリに 2 を書き込みます。 。 。
3 つのレベルの分類があると仮定し、製品テーブルに 3 つのフィールド (cate、cate1、cate2) を追加します。
製品がどのサブカテゴリに属する​​かを、親からレベル 2 の子までの 3 つのフィールドすべてに入力します
フィルタリングする場合は、以下に基づいて受信した cateid を取得し、最初にこのカテゴリのフロアを見つけてから、その上位カテゴリ ID をすべて見つけます
残りは、取得したすべての ID を条件としてフィルタリングすることです
ここにキーがあります。BTREE インデックスを構築する必要があります。 cate から cateN までの順序です。すべてが含まれています
同じ量のデータを使用する方法 2 の方がはるかに高速ですが、サブカテゴリを移動するときに製品テーブルを変更する必要があるという欠点があります

サブカテゴリ番号があるのは奇妙ですが、まだですかサブカテゴリの製品について心配する必要がありますか?

これにはサブカテゴリも関係します。サブカテゴリはすべて子孫カテゴリなので、最初に思いつくのは再帰です

サブカテゴリの 1 層だけであれば、確かに扱いは簡単ですが、 Infinitus 分類、サブカテゴリーのレベル数 全く不明

案を考えてみました

データ量が多いのか分かりません
中小企業の Web サイトの場合、親カテゴリー ID を取得した後、すべてのサブカテゴリ ID を取得し、それらをマージします: 2,5 ,6,7,8
product テーブルの SQL ステートメントに移動し、in キーワードを使用して使い方を確認し、検索してください...
Iインデックスを使用できるかどうかわかりませんか?

データ量が比較的大きい場合は、効率を高めるために冗長性を使用します。
分類テーブルにフロア フィールドを追加し、親カテゴリに 0、第 1 レベルのサブカテゴリに 1、第 2 レベルのサブカテゴリに 2 を書き込みます。 。 。
3 つのレベルの分類があると仮定し、製品テーブルに 3 つのフィールド (cate、cate1、cate2) を追加します。
製品がどのサブカテゴリに属する​​かを、親からレベル 2 の子までの 3 つのフィールドすべてに入力します
フィルタリングする場合は、以下に基づいて受信した cateid を取得し、最初にこのカテゴリのフロアを見つけてから、その上位カテゴリ ID をすべて見つけます
残りは、取得したすべての ID を条件としてフィルタリングすることです
ここにキーがあります。BTREE インデックスを構築する必要があります。 cate から cateN までの順序 すべてが含まれます
同じ量のデータでは方法 2 の方がはるかに高速ですが、サブカテゴリを移動するときに製品テーブルを変更する必要があるという欠点があります

私は Infinitus 分類を使用しており、サブカテゴリ レベルは必ずしも確実ではありません。以下にサブカテゴリがあるかもしれません。その後、最初に再帰を考え、カテゴリ テーブルにパス フィールドを追加しました。 最初に全部出してしまうと、「1 つクリック」がなくなり、「カテゴリ、現在のカテゴリとそのサブカテゴリにあるすべての商品をリストアップ」ということになります

クリックするだけで出てくるのですから、当然です。第 1 レベルのサブカテゴリが表示され、もう一度クリックすると再び表示されます。これは統一されたスタイルです

つまり、一度にすべてを取り出し、親の分類手順に従ってレベルごとに読み取ります

再帰は必要ありません。上記の「階層」フィールドで見つけることができます表 クリックした分類の分類番号が将来世代に分類されます。
たとえば、クリックされたカテゴリの ID 番号が 18 の場合、「%18-%」のような cate_path または「%-18%」のような cate_path を使用してフィルタリングできます。

無限レベルなどというキーワードは言っていませんね！

このアイデアはまだ 4 階の 2 番目の方法だと思います。これは、クエリしたい cateid の親カテゴリ ID をすべて捨てて、それらをマージして確認することです
を使用しても問題ないはずです、または -
製品の cateid フィールドを次のように保存します。形式: 1,5,8,21 は、レベル 1 分類からレベル N 分類までです
cateid=8 のすべての製品を確認したい場合は、まず上位 2 つのレベルを見つけますカテゴリ 5 と 1 を生成し、文字列 1,5, 8 を生成します
その後、クエリ ステートメントで '$cateid %' のような cateid を使用します

さらに、必要に応じて

cateid=8 のすべての製品をチェックするには、まず上位 2 つの分類 5 と 1 を見つけて、文字列 1,5,8 を生成します

このステップの文字列はデータベースに書き込むことも、すべての分類 ID に対応するクエリ文字列を書き込むこともできます実際の実行時間はスキップできます ^ ^

私 フィルタリング方法に問題があると思います。 IDが8の場合はどうなるでしょうか？ 「%8%」などの式には、18、81、82 などが含まれます。

このメソッドの式を変更するだけです。 0 の ID もクリックできる場合、最終的に、検索された ID に加えて、現在クリックされている ID 自体も in に含まれることになります。それ以外の場合は、前後に「-」を付けずに 0 のみが表示されるため、他に何も追加する必要はありません。

無限レベルなんてキーワード言ってないよ！

このアイデアはまだ 4 階の 2 番目の方法だと思います。これは、クエリしたい cateid の親カテゴリ ID をすべて捨てて、それらをマージして確認することです
を使用しても問題ないはずです、または -
製品の cateid フィールドを次のように保存します。形式: 1,5,8,21 は、レベル 1 分類からレベル N 分類までです
cateid=8 のすべての製品を確認したい場合は、まず上位 2 つのレベルを見つけますカテゴリ 5 と 1 を生成し、文字列 1,5, 8 を生成します
その後、クエリ ステートメントで '$cateid %' のように cateid を使用します

- を使用するか、または使用するかに違いはありません。これを使用すると、親カテゴリを検索する必要はありません。

これは簡単です。チェックを続けてください。

メインカテゴリ ID からサブカテゴリをクエリし、サブカテゴリ ID から 3 番目のレベルをクエリし、3 番目のレベル ID から 4 番目のレベルをクエリします...

もちろん、サーバーはそのような苦痛に耐えることができなければなりません。

無制限であるかどうかに関係なく、これがクエリです。近道はありません。

これは簡単です。チェックを続けてください。

メインカテゴリ ID からサブカテゴリをクエリし、サブカテゴリ ID から 3 番目のレベルをクエリし、3 番目のレベル ID から 4 番目のレベルをクエリします...

もちろん、サーバーはそのような苦痛に耐えることができなければなりません。

無制限であるかどうかに関係なく、これがクエリです。近道はありません。

cate_path フィールドがあるため、これは必要ありません。

このメソッドの式を変更するだけです。 0 の ID もクリックできる場合、最終的に、検索された ID に加えて、現在クリックされている ID 自体も in に含まれることになります。それ以外の場合は、前後に「-」を付けずに 0 のみが表示されるため、他に何も追加する必要はありません。

兄弟、あなたは本当に思慮深いです。180 には 18 も含まれています。確かにレバレッジを加える必要があります

私はまだ会社に入ったばかりで、詳しく見る時間がありません
あなたが議論していることは次のとおりです。カテゴリへのパスを追加し、 in を使用して製品の SQL ステートメントをクエリします?
無限レベルの分類に in を使用する効率は...多くの ID でしょうか
幸いなことに、 in はインデックスを使用できますが、mysql に in のソート機能があるかどうかはわかりません。そうでない場合は、インデックス ツリーを走査する必要があります。最初から最後まで、それでも複雑さは変わりません ID の数を掛ける必要があります

4 階と 10 階で話したものはすべて、クエリを高速化するためのソリューションです
それを実装する方法はありません
cateid を取得した後、メモリ キャッシュから php を使用します (カテゴリの編集時に一度生成されます)。変数ハッシュの変数ハッシュは分類パスを読み取ります。このステップにはほとんど時間がかかりません。次に、パス文字列を直接使用してすべてのデータ セットを見つけます。インデックスツリーの助けを借りて一度に、非常に高速です

天気が少し急いでいて申し訳ありませんが、間違いがあれば修正してください
。