各製品に多くのパラメータがある複数の製品の製品テーブルを設計する方法

Question

私にはテーブルデザインの経験があまりありません。私の目標は、複数の種類の製品 (テレビ、モバイル、コンピュータなど) をサポートするという要件を満たす 1 つ以上の製品テーブルを作成することです。製品の各タイプには、異なるパラメータのセットがあります。たとえば、電話機には色、サイズ、重量、オペレーティング システムなどが含まれます。コンピュータにはCPU、ハードドライブ、メモリなどが搭載されています。パラメータセットは動的である必要があります。任意のパラメータを追加または編集できます。製品タイプごとに個別のテーブルを作成せずに、これらの要件を満たすにはどうすればよいでしょうか?

P粉930448030 · Answer

＃＃＃@石の心＃＃＃

私は常に EAV と MVC を使用します。

@ビル・カービン

ここで言及したすべての内容:

データ検証

属性名のスペル検証
必須の列/フィールド
依存プロパティの破棄の処理

私の意見では、このようにデータベースを使用することは、石で釘を打つようなものです。石を使って行うこともできますが、このアクティビティのために特別に設計された、より正確なハンマーを使用すべきではないでしょうか。

この問題は、データの一部に対して少数のクエリを実行し、それをテーブルレイアウトに処理することで解決できます。 600 GB の商品データがある場合でも、このテーブルから各行のデータを取得する必要がある場合は、バッチで処理できます。

さらに、クエリのパフォーマンスを向上させたい場合は、レポートやグローバルテキスト検索などの特定の操作を選択し、必要なデータを保存し、定期的に (30 分ごとなど) 再生成するインデックステーブルを準備できます。

追加のデータストレージのコストについて心配する必要もありません。データストレージのコストは日々低くなっています。

アプリケーションによって実行される操作のパフォーマンスがまだ心配な場合は、いつでも Erlang、C、Go 言語を使用してデータを前処理し、メインアプリケーションで最適化されたデータをさらに処理できます。

P粉504920992 · Answer

記述した型階層をモデル化するには、少なくとも次の 5 つのオプションがあります:

単一テーブルの継承: すべてのタイプのすべての属性を格納するのに十分な列を備えた、すべての製品タイプに対して 1 つのテーブルを使用します。これは、各行に多くの列があり、その行のほとんどが NULL であることを意味します。
クラステーブルの継承: 製品のテーブルを使用して、すべての製品タイプの共通属性を保存します。次に、各製品タイプのテーブルを使用して、その製品タイプに固有の属性を保存します。
特定のテーブルの継承: 共通の製品属性のテーブルはありません。代わりに、製品タイプごとに 1 つのテーブルを使用して、共通の製品属性と製品固有の属性を保存します。
シリアル化された LOB: 製品に対して 1 つのテーブルを使用して、すべての製品タイプの共通属性を保存します。追加の列には、XML、YAML、JSON、またはその他の形式の半構造化データの BLOB が保存されます。この BLOB を使用すると、各製品タイプに固有の属性を保存できます。ファサードやメメントなど、複雑なデザインパターンを使用してこのプロセスを記述することができます。ただし、いずれにせよ、SQL で簡単にクエリできないプロパティ BLOB があるため、BLOB 全体をアプリケーションに返し、そこで並べ替える必要があります。
Entity-Attribute-Value: 製品のテーブルと、属性を列ではなく行に回転させるテーブルを使用します。 EAV はリレーショナルパラダイムにおいて効率的な設計ではありませんが、今でも多くの人が使用しています。これは、別の回答で述べた「プロパティパターン」です。問題点のいくつかについては、StackOverflow で eav タグを使用した他の質問を確認してください。

これについては、Extensible Data Modeling というデモで詳しく書きました。

EAV についてのその他の考え: 多くの人は EAV を気に入っているようですが、私はそうではありません。これは最も柔軟なソリューションであるため、最良のソリューションであると思われます。ただし、この格言 TANSTAAFL を思い出してください。 EAV の欠点のいくつかを次に示します:

列を必須にすることはできません (NOT NULL と同等)。
SQL データ型を使用してエントリを検証できません。
属性名の一貫性のあるスペルを保証できません。
ルックアップテーブルなどの特定の属性の値に外部キーを配置することはできません。
従来のテーブルレイアウトの結果を取得することは複雑でコストがかかります。複数の行の属性を取得するには、属性ごとに JOIN が必要だからです。

EAV によって提供される柔軟性には他の領域での犠牲が必要となり、元の問題を従来の方法で解決した場合と同じくらい (またはさらに悪化) コードが複雑になる可能性があります。

そして、ほとんどの場合、そのレベルの柔軟性は必要ありません。製品タイプに関するご質問では、製品固有の属性を格納するテーブルを製品タイプごとに作成する方が簡単です。これにより、同じ製品タイプのエントリに対して少なくとも一定の一貫した構造を適用できます。

各行に異なるプロパティのセットを許可する場合にのみ、EAV を使用します。製品タイプのセットが限られている場合、EAV は過剰です。クラステーブルの継承が私の第一選択です。

2019 更新: 「多数のカスタムプロパティ」問題の解決策として JSON を使用している人を見るほど、私はこの解決策が好きではなくなります。特別な

JSON 関数を使用してそれらをサポートしたとしても、クエリは複雑になりすぎます。 JSON ドキュメントを保存するには、通常の行と列に保存するよりも多くのストレージスペースが必要です。

基本的に、リレーショナルデータベースでは、これらのソリューションはどれも簡単でも効率的でもありません。「可変特性」を持つという概念全体は、関係理論と根本的に矛盾します。

結局のところ、データのクエリ方法に基づいてこれらのソリューションの 1 つを選択する必要があります。これは、

アプリケーションにとって最も最悪のソリューションに基づいています。したがって、データベース設計を選択する前に、データをクエリする方法を知っておく必要があります。アプリケーションにとっては、いずれか 1 つのソリューションが最適な選択となる可能性があるため、1 つのソリューションが「最適」ということはありません。