エンティティ属性値モデル-パフォーマンスの代替？

最初 、このモデルを使用すると、データのクエリがはるかに簡単になる場合があります。数日前にここで質問しました また、一部のユーザーは、データのクエリを簡単にするためにモデルを1NF形式に変更しなかった理由を提案しました。彼らは私がこのデザインに固執していることに気付いたときだけ、質問に対するいくつかの答えを提供しました。重要なのは、私は幸運にも12列しか合計できないということです。そうでなければ、私のテーブルに300列が含まれている場合、おそらくユーザーはその問題のクエリを作成することを気にしませんでした。 :-)

2番目 、データベースによって自然に課せられるいくつかの制限のために、この設計の実装がより簡単な場合があります。 meta_keyの場合 値には30文字を超える長い値が含まれています。値を短くしてどこかでマッピングを行う必要があります。そうしないと、これが唯一の選択肢になる可能性があります。

最後に 、パフォーマンスは非常に重要です。それは本当だ。ただし、一方で、パフォーマンスを向上させるために適用できる特定の手法があります。適切なインデックスの作成、テーブルのパーティション化など。

この場合、テーブルのサイズは非常に小さくなります。したがって、計算量が多く、結合や集計が複雑になるなど、クエリが非常に複雑でない限り、また、アプリケーションが小さな時間の割合に敏感でない場合は、このモデルを採用してもパフォーマンスに影響はないと思います。

最後に 、それでもパフォーマンスについてあまり懸念がある場合は、両方のモデルを作成し、ランダムまたは実際のデータを入力して、計画コストを分析し、どちらのモデルがニーズに適しているかを確認することをお勧めします。