製品リスト（関連する画像、画像、その他のデータ）のMySQLのベストデータベース構造

Question

私は製品リストのデータベースを作成していますが、構造を視覚化するのが難しいです。主なリストは、システムによって分割され、それが使い分けられます。これらのすべてに対応する画像が表示されます。さらに、各システム固有のタブ付きメニューがあり、説明、仕様、ダウンロード、およびマニュアルが表示されます。このように： - メニュー01 -

システム01のすべての画像

• 使用法01 - >画像（サブセット）
• 使用法02 - >画像（サブセット）
• 使用法03 - >画像（サブセット）

システム02 - メニュー02 - すべての画像

• 解説01 - >画像（部分集合）
• 使用法02 - >画像（部分集合）
• 使用法03 - >画像（部分集合）

システム03 - メニュー03 - 全て画像

• 使用法01 - >画像（部分集合）
• 使用法02 - >画像（部分集合）
• 使用法03 - >画像（部分集合）

私はhtmlテンプレートを持っています。アイデアは、システムによって製品を選択することによって、タブ付きメニュー、メイン画像、およびサムネイル画像が表示されるということです（私はこれにAjaxを使用しています）。しかし、用途によって製品を選択することも可能であり、これは2つ以上のシステムに該当する可能性があります。

私の問題は構造です。私は一般的な考え方を持っていますが、データベースを使って作業を始めたので、このプロジェクトでは最適ではないかもしれません。私は3つのテーブルを考えました：

• 最初のテーブルはタブ付きのメニューと画像を持つすべてのシステムを持っています。
• 2番目の表には、用途と対応するシステムIDとイメージIDがあります。
• 第3のテーブルは前のテーブルと関連しなければならないが、私はどのように、またはそれが正しいアプローチであるかわからない。

画像を保存する際には異なるが、関連する質問がベストプラクティスになります。私はパスを格納する方が効率的だと思うし、人に「varchar」や「blob」のどちらかをタイプするよう勧めているのを読んだことがあります。

私はそれが一般的な質問であることは知っていますが、誰かが光を当てることを願っています。ありがとう。

Answer 1

私は一枚の紙を取り出し、あなたの関係を表すためにあなたの「エンティティ」とラインを表す円を描き始めます。一般的に言えば、Entity（モデル化するもの）から始まり、それについて覚えておきたいフィールドのリストを開始します。各フィールドは、そのエンティティに直接関連していて、色、サイズなどのように、それ自体では存在しません。

同じフィールドに複数の選択肢がある場合は、別のテーブルが必要な場合があります。これらの選択肢のリストを1つ保存する場合は、カラー表のような2つの表と、両方の表の主キーのみを参照する多対多表が必要になることがあります。この方法で、赤色の色を選択し、赤色のすべての製品を表示したり、製品を選択したり、関連する色をすべて表示することができます。

プライマリキーはレコードにアクセスする主な方法であり、常に一意である必要があり、通常、テーブルのレコードがディスクに格納される方法のソート順を指定します。

外部キーは、通常、他のテーブルの主キーを参照するテーブル内のフィールドです。

良いスタートがありますdatabase normalization.