0

私は mysql をサポートする php アプリケーションを作成します。アイデアは、Web サイト テンプレートから追加および削除できる特性を含むフォーム フィールドに基づいています。フォーム フィールドを介して、作成された特性の値を挿入します。チェックボックス、ラジオ グループ、選択、テキストなど、すべてのタイプを使用できます。一部の選択は連鎖できます。その説明は、全体像を把握するためのものでした。

私のデータベース設計には、次の 3 つのテーブルが含まれています。

FIRST を含む項目コンテンツ - 製品。

特性の値を含む 2 番目 - charact_values;

THIRD には、その 2 つのテーブル値をリンクする、行ごとに 1 番目と 2 番目のテーブルの ID が含まれている必要があります。

それで、私は今、各製品に属する値です。

重複した値は必要ありません。3 番目のテーブルにリンクするだけです。ユーザーが製品にいくつの特性を追加するかはわかりませんが、そのスキーマでそれが可能です。

私が恐れているのは、ユーザーが 5,000 個の製品を配置し、各製品に約 100 個の特性があり、3 番目のテーブルに約 500,000 行あるとどうなるかということです。

3番目のテーブルには多すぎますか?その機能に使用できる他のデータベース設計が存在する可能性があります。一部のテーブルで大量の行を生成しない別のスキーマを理解できません。

4

1 に答える 1

0

私の意見では、スキーマはシナリオを実装するための正しい正規化された方法です。3 番目のテーブルが何万ものレコードになる可能性がありますが、それらすべてを一度にクエリするつもりはありません。

例。製品リストを表示すると、製品を選択したときにのみ特性を照会できます。したがって、大規模なデータベースにもかかわらず、問題が発生するとは思いません。

このスキーマ自体を先に進めます。

于 2012-11-08T07:51:05.820 に答える