上記はカテゴリ テーブルです。製品テーブルは、製品が属するカテゴリを決定する、関連するカテゴリ テーブルの 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 の方がはるかに高速ですが、サブカテゴリを移動するときに製品テーブルを変更する必要があるという欠点があります
サブカテゴリ番号があるのは奇妙ですが、まだですかサブカテゴリの製品について心配する必要がありますか?
データ量が多いのか分かりません
中小企業の 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 の方がはるかに高速ですが、サブカテゴリを移動するときに製品テーブルを変更する必要があるという欠点があります
クリックするだけで出てくるのですから、当然です。第 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が8の場合はどうなるでしょうか？ 「%8%」などの式には、18、81、82 などが含まれます。
無限レベルなんてキーワード言ってないよ！
このアイデアはまだ 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 番目のレベルをクエリします...
もちろん、サーバーはそのような苦痛に耐えることができなければなりません。
無制限であるかどうかに関係なく、これがクエリです。近道はありません。
私はまだ会社に入ったばかりで、詳しく見る時間がありません
あなたが議論していることは次のとおりです。カテゴリへのパスを追加し、 in を使用して製品の SQL ステートメントをクエリします?
無限レベルの分類に in を使用する効率は...多くの ID でしょうか
幸いなことに、 in はインデックスを使用できますが、mysql に in のソート機能があるかどうかはわかりません。そうでない場合は、インデックス ツリーを走査する必要があります。最初から最後まで、それでも複雑さは変わりません ID の数を掛ける必要があります
4 階と 10 階で話したものはすべて、クエリを高速化するためのソリューションです
それを実装する方法はありません
cateid を取得した後、メモリ キャッシュから php を使用します (カテゴリの編集時に一度生成されます)。変数ハッシュの変数ハッシュは分類パスを読み取ります。このステップにはほとんど時間がかかりません。次に、パス文字列を直接使用してすべてのデータ セットを見つけます。インデックスツリーの助けを借りて一度に、非常に高速です
天気が少し急いでいて申し訳ありませんが、間違いがあれば修正してください
。
![[Web フロントエンド] Node.js クイック スタート](https://img.php.cn/upload/course/000/000/067/662b5d34ba7c0227.png)
