テーブルが多すぎます。 MySQLは結合で61個のテーブルしか使用できません

EAVデザインを使用していて、可変数の属性から単一の行を再構築しようとしています。これは、EAV設計を使用して遭遇する多くの地雷の1つを示しています。つまり、1つのSQLクエリで実行できる結合の数には実際的な制限があります。

特にMySQLでは、ご存知のように厳しい制限があります。ただし、他のRDBMSブランドでも、結合のコストはテーブルの数に対して幾何学的であるため、効果的な制限があります。

EAVを使用する場合は、SQLで行を再構築しないでください 従来のデータベース設計であるかのように。代わりに、エンティティIDでソートされた行として属性をフェッチします。次に、アプリケーションコードでそれらを後処理します。これは、1つのステップでデータをダンプできないことを意味します。つまり、属性行をループするコードを記述し、データを出力する前にデータの各行を再編成する必要があります。

EAVは便利なデータベース設計ではありません。それを使用することには多くの費用のかかる欠点があり、そのうちの1つにぶつかっただけです。

http://www.simple-talk.com/opinion / opinion-pieces / bad-carma / EAVの使用が1つのビジネスをどのように運命づけたかについての素晴らしい話のために。

また、http://en.wikipedia.org/wiki/Inner-platform_effect> EAVはこのアンチパターンの例だからです。

• すべての製品タイプに共通する属性ごとに、ベーステーブルに実際の列を定義します。製品名、価格、在庫数など。正規の製品を想像してみてください。 エンティティであるため、このセットにできるだけ多くの属性を含めることができます。

• タイプTEXTの列をもう1つ定義します 指定された各製品タイプのすべての追加属性。この列にシリアル化されたLOB として保存します XML、JSON、YAML、独自の自家製DSLなど、適切な形式の属性を選択します。

  これをSQLクエリの単一の列として扱います。これらの属性に基づいて実行する必要のある検索、並べ替え、または表示では、TEXT全体をフェッチする必要があります。 アプリケーションへのblobはそれを逆シリアル化し、アプリケーションコードを使用して属性を分析します。