PHPでの複数階層のカテゴリ表示
解決済
回答 1
投稿
- 評価
- クリップ 1
- VIEW 3,477
お世話になります。
簡単なECサイトを構築しているのですが、複数階層のカテゴリを実現する方法がわからず、アドバイスいただきたいです。
DB：MySQL
カテゴリA
カテゴリB
カテゴリC
カテゴリD
カテゴリE
カテゴリテーブル
カテゴリID カテゴリ名 親カテゴリID
1 カテゴリA 0
2 カテゴリB 1
3 カテゴリC 2
4 カテゴリD 0
5 カテゴリE 0
例えば、上記カテゴリに対しそれぞれ商品が紐付けられます。
カテゴリCを開いた際に、パンくずリストにはカテゴリAとカテゴリBを取得しておく必要がありますが、
どのように最上位階層であるカテゴリAを取得するか悩んでいます。
WEBサイトを見ていると、DBの木構造を理解しないとダメ、再帰的にSQLを発行するのはパフォーマンス的にNGなどの記述がありましたが、こういった部分の話を理解し使うようになるためには、具体的にどういった知識が必要となりますでしょうか。
データベース系の書籍を読むのが良いのか、PHP系の書籍を読むのがいいのか、
オススメの書籍、知っておくべきキーワードなどご教示いただけると大変助かります。
誠に恐れ入りますが、ご回答いただけますと幸いです。
よろしくお願いいたします。
-
気になる質問をクリップする
クリップした質問は、後からいつでもマイページで確認できます。
またクリップした質問に回答があった際、通知やメールを受け取ることができます。
クリップを取り消します
-
良い質問の評価を上げる
以下のような質問は評価を上げましょう
- 質問内容が明確
- 自分も答えを知りたい
- 質問者以外のユーザにも役立つ
評価が高い質問は、TOPページの「注目」タブのフィードに表示されやすくなります。
質問の評価を上げたことを取り消します
-
評価を下げられる数の上限に達しました
評価を下げることができません
- 1日5回まで評価を下げられます
- 1日に1ユーザに対して2回まで評価を下げられます
質問の評価を下げる
teratailでは下記のような質問を「具体的に困っていることがない質問」、「サイトポリシーに違反する質問」と定義し、推奨していません。
- プログラミングに関係のない質問
- やってほしいことだけを記載した丸投げの質問
- 問題・課題が含まれていない質問
- 意図的に内容が抹消された質問
- 過去に投稿した質問と同じ内容の質問
- 広告と受け取られるような投稿
評価が下がると、TOPページの「アクティブ」「注目」タブのフィードに表示されにくくなります。
質問の評価を下げたことを取り消します
この機能は開放されていません
評価を下げる条件を満たしてません
質問の評価を下げる機能の利用条件
この機能を利用するためには、以下の事項を行う必要があります。
- 質問回答など一定の行動
-
メールアドレスの認証
メールアドレスの認証
-
質問評価に関するヘルプページの閲覧
質問評価に関するヘルプページの閲覧
checkベストアンサー
+2
とても奥深く重要なテーマですね。自分は専門外の分野ですが、ご参考になればと思い回答します。
まず、木構造の扱い方とパフォーマンスの問題は分けて考えた方が良いです。
1. 木構造の扱い方について
DB 木構造 という簡単なキーワードでググっただけでも、下記のようなとても優れた解説ページを発見することができました。
取り敢えず、下記ページをじっくり読み込んでみてはいかがでしょうか？
SQLで木と階層構造のデータを扱う（１）
SQLで木と階層構造のデータを扱う（２）
SQLで木と階層構造のデータを扱う（３） ← gihyo.jpのSQLアタマアカデミーへのリンクになっています
⇒ 書籍なら、同著者の「達人に学ぶDB設計 徹底指南書」がおすすめです。
また、各モデルの比較は下記がよくまとまっています。
2. 木構造探索のパフォーマンスについて
確かに「再帰的にSQLを発行するのはパフォーマンス的にNG」は正しいですが、パフォーマンスの問題は常に、「データ量や階層の深さ」vs「実装やメンテナンスのしやすさ」vs「検索速度」など相対する複数の要素間でのトレードオフの問題です。
いまゲストユーザーさんが構築中のECサイトで扱う予定の「複数階層のカテゴリ」は、どの程度の規模・複雑度でしょうか？
規模・複雑度や更新頻度がそれ程でもないのであれば、適切なSQLを書く限りDBアクセスが大きなボトルネックにはならないと思いますので、実装のしやすさやメンテナンス性を重視すれば良い（言い換えると必要なら再帰的にSQLを使用しても良い）と考えます。
しかし、もしもパフォーマンスが問題になりRDBでは対応が困難（=SQLのチューニングだけでは無理）なのであれば、インメモリデータベース、分散Key-Valueストア、LDAPなどの、いわゆるNoSQLの利用を検討することもできます。
一方、従来とは全く異なるアプローチ（実際には歴史が古いが）として、ユニケージ開発手法というのも有ります。
きわめてザックリ説明すると、全てのデータをテキストベースで管理し、シェルスクリプトの特性を最大限に活用してシンプル、高パフォーマンスかつメンテナンス性の高いシステムを短期間に構築するという手法です。
正しく実装すると、億単位のレコード数のデータに対してもほぼ瞬時に検索可能です。
その理念を部分的に取り込むならば、
- 階層カテゴリの情報は従来通りRDBで管理する
- パンくずリストに相当する階層データはテキストベースで保持する（仮に階層リストと呼ぶ）
- 階層リストはカテゴリに追加・変更のあった時のみ更新する（メンテナンス時はリアルタイム性を重視しない）
- 通常のページ移動時には階層リストを検索することでパンくずリストを生成する
⇒ イメージとしては、現在のページ名で階層リストをgrep→ヒットした行がそのままパンくずリスト
のような仕組みにすると、相当複雑・大規模な階層カテゴリでも、速度とメンテナンス性を両立させることが可能だと思います。
結論としては、扱う予定の「階層カテゴリ」の「規模・複雑度」や「更新頻度」に応じて、パフォーマンス要件を満たす範囲でなるべくシンプルな実装にした方が良いということです。
投稿
-
回答の評価を上げる
以下のような回答は評価を上げましょう
- 正しい回答
- わかりやすい回答
- ためになる回答
評価が高い回答ほどページの上位に表示されます。
-
回答の評価を下げる
下記のような回答は推奨されていません。
- 間違っている回答
- 質問の回答になっていない投稿
- スパムや攻撃的な表現を用いた投稿
評価を下げる際はその理由を明確に伝え、適切な回答に修正してもらいましょう。
15分調べてもわからないことは、teratailで質問しよう！
- ただいまの回答率 88.09%
- 質問をまとめることで、思考を整理して素早く解決
- テンプレート機能で、簡単に質問をまとめられる
2016/01/06 10:23
大変ためになる内容で、本当に感謝しております。
実装イメージが少し湧いてきました。
仰るように、サイト規模や目的に応じたDB設計が重要となりますね。
ご教示いただいたサイトはしっかり読み込みます。
また、ご紹介いただいた書籍も早速購入しました。
pi-chanさんのご回答も何度も読みなおしながらより理解を深めていこうと思います。
誠にありがとうございました。