明らかに、この質問はより多くの情報がなければ答えられないので、拡大させてください。
約1000店舗の店舗データベースを構築しています
それらは、13の主要な製品カテゴリに分類されます。
これらの 13 の主要なカテゴリには、それぞれ約 4 ～ 5 つのサブカテゴリがあります。
それらの 4 つまたは 5 つ (合計約 65) には、それぞれ約 4 つまたは 5 つの独自のものがあります。
私が行ったことは、すべての単一の親とその直接の子のテーブルを作成することです。次に、それぞれの子とその子のテーブル。
ロジックに関しては、私のプログラミングのニーズを満たしますが、これほど多くのテーブルを持つことは完全に非正統的であり、それを行うためのより良い方法があるかどうか疑問に思っています.
また、クエリを実行すると、多くのテーブルがシステムを過負荷にしたり遅延させたりするのではないかと考えています。
各カテゴリにparent_idを割り当てただけの2つのテーブルですべてを行うこともできましたが、視覚的な観点からは、非常に組織的または階層的に見えませんでしたが、これは完璧なツリーのようです.
適切なインデックスを付けたリレーショナル データベース構造 (1 対多または多対多の関係) を使用します。カテゴリごとに個別のテーブルを持つことは、論理的に意味がありません。これが、リレーショナル データベースが発明された理由です。
あなたのソリューションは機能するはずですが、データ的な意味では、あまり良い方法ではありません。
より具体的にするには
のようなデータベース構造
TABLE categories:
id title parent_id(NULL)
次に、PHP で再帰を使用して、これから取得した結果を並べ替えます。
あなたが説明した問題に対して、200のテーブルはやり過ぎです。店舗に関するデータを 1 つのテーブルに、カテゴリに関するデータを別のテーブルに、サブカテゴリに関するデータを 3 番目のテーブルに、最後にサブサブカテゴリに関するデータを 4 番目のテーブルに格納できます。次に、特定の店舗と特定のサブサブカテゴリに関連するデータを 5 番目のテーブルに格納できます。
外部キー/主キー参照定義を使用してこれらのテーブルの行を他のテーブルの行に結合し、必要に応じて結合を使用してデータを結合します。
はるかにシンプルで、パフォーマンスが向上し、将来性が保証されています。データベースの構造を変更せずに新しいストアを追加できます。それだけでなく、データベースを構築したら、データに対してさまざまなクエリを実行できます。
同じデータをさまざまな方法で活用することが、データベースの真髄です。あなたの構造では、新しい方法でデータを活用したいときはいつでも、新しいプログラムを書かなければなりません。従来の設計では、SQL でクエリを記述するだけです。
ところで、400 ほどのテーブルを含むデータベースを見たことがあります。しかし、そのデータベースは、中規模の大学のすべての管理データを管理していました。学生、コース、登録、成績から卒業生の寄付、高校の成績証明書、スポーツ イベント、駐車スペースまで、あらゆる情報を収集します。あなたの問題はそれほど複雑ではありません。
すべてのテーブルに同じフィールドまたはほとんど同じフィールドがあり、それらが同じもの (つまり製品) を表している場合、2 つのテーブルのみを使用するソリューションが、このデータベースを設計するためのより標準的な方法です。1 つのテーブルには、すべての製品とそれらが分類されるカテゴリ (最も具体的なカテゴリ) が一覧表示され、もう 1 つのテーブルにはカテゴリが一覧表示されます。この表に表示される階層情報を処理するさまざまな方法については、この質問を参照してください。ネストされたセット モデルも、ここでのニーズに適合する場合があります。(その質問をした人のニーズを満たしていないため、その質問では説明しません。) 選択したモデルによっては、モデルを実装するために 3 つ目のテーブルを追加する必要がある場合があります。
いくつかの考慮事項:
複数テーブルのシナリオでは、製品/カテゴリなどが成長するにつれてテーブルをどんどん追加し続ける必要がありますが、ルックアップをより高速に保ち (より少ないレコードの完全なテーブル スキャン)、クエリをよりクリーンにし、関係をより健全に保ちます。
通常、データを取得するために自己結合する 2 つのテーブルのシナリオでは、すべてのデータがこれらの少数のテーブルに存在するため、ルックアップが遅くなる可能性があります。また、個人的な経験から、特に n レベルの親子関係になると、同じテーブル内に非常に多くのコードと関係を維持するのは面倒です。Oracleには、クエリを簡単にするような状況向けの関係解析SQL構文があります.しかし、MySQLにはそれらが欠けていると思います..
私があなただったら、すべてのことを考慮して、私は最初の構造に行きます..たぶん、いくつかの子と親の関係をフラット化しますが、ほとんどはアトミックに保ちます. （ちなみに、私は400以上のテーブルを持つ（レガシー）MySQLデータベースを扱ってきたので、200以上のテーブルで問題ないと思います）
最も重要な情報である負荷を提供していないため、この質問には答えられません。このデータベースを使用するユーザーは何人ですか? 同様に重要なのは、インフラストラクチャのホストにどの会社を使用していますか?
また、コードが適切に記述されていないと、データベースのパフォーマンスが低下します。
それはさておき、ページごとに小さなタイミング スクリプトを作成します。各クエリにかかる時間を特定し、予想されるユーザー数を掛けます。1 秒間に 400 件のクエリが予想される場合、コードの記述方法やインフラストラクチャのホストに誰を使用するかなどは、すぐに非常に重要になります。