投稿、イベント、ページを保存するためのエンティティ属性値テーブルと単一テーブル
投稿、ページ、イベントを保存するために、フィールドの多い個別のテーブルを使用するのか、それとも基本的なフィールドを持つテーブルを使用するか、オプションのフィールドにEAVテーブルを使用するのかを決定しようとしています。また、EAVを使用すると、実際にデータベースをまったく変更せずに（アプリケーションコードをわずかに変更するだけで）、各エンティティにさらに「属性」を追加できます。
ただ、気になるのはパフォーマンスです。 EAVは、このようなシナリオ（イベントなどのデータを格納する）でパフォーマンスを低下させますか？
また、後でモデルにフィールド/属性を追加する必要がある場合（仕様が変更され、システムを拡張する必要がある場合）に備えて、event_metaなどのEAVテーブルをデータベースに追加する価値はありますか？
現在、私は2つのオプションを考えることができます：
EAVテーブルを使用せず、エンティティタイプ（投稿、ページ、イベント）ごとに1つのテーブルを持ち、エンティティテーブルにすべてのデータ（約15のフィールド）がある。
EAVテーブルを使用して、通常はユーザーが入力しないオプションのデータを格納します（これにより、エンティティテーブルに空のフィールドが多数含まれるのを防ぐことができます）が、必須で重要なデータはすべてエンティティテーブルに格納します。
また、オプション2の場合、実際には、3つのテーブルの投稿、ページ、およびイベントの代わりに、1つの一般的なテーブル「投稿」だけを持ち、EAVテーブルでより多くの属性値行を使用できます（そして投稿にtypeフィールドがあります）テーブル）。ただし、これによりパフォーマンスがさらに低下する可能性があります。
オプション1は実装がはるかに簡単です。ただし、オプション2を使用すると、データベースを調整する必要がなくなるため、将来のエンティティの拡張が容易になる可能性があります。
考慮すべきもう1つの重要なことは、パフォーマンスです。 events_metaに数百万の行があるとどうなりますか。誰かがイベントを表示するたびに、アプリケーションは両方のテーブルに対してクエリを実行する必要があり、これは非常に大きくなるため、パフォーマンスが低下すると思います。
それでは、どのオプションを自分の状況に使用する必要がありますか？
データベースにデータベースを構築しないでください。パフォーマンスは悪く、それを管理するコードも同様です。アプリケーションロジックを駆動する属性は、目的に一致する名前を持つ適切なテーブル上のデータベースの実際の列である必要があります。アプリケーションに対して透過的な任意の数のユーザー定義属性をサポートする必要がある場合は、EAVを使用します。
スキーマの変更は、データベースアプリケーションのメンテナンスの一部です。それを避けようとすると狂気につながります。
@kevin clineに同意します。これらのフィールドを列（インデックス付けなど）として持つパフォーマンスを簡単に最適化できるので、フィールドを属性ではなく列として固定およびロジック管理する必要があります。現在、パフォーマンスはストレージよりもはるかに重要です（ストレージが安価になっています）。そのため、最高のパフォーマンスを提供する設計を構築する必要があります。私の経験から、Application ORで各Attribute\Fieldレベルでアクションをログに記録する必要がある場合にのみ、新しいフィールドを作成する必要がある場合にのみ、フィールドを属性として作成する必要があると思います。上記の2つの特別な要件はありません。通常のアーキテクチャ（EAVではありません）でいつでも使用できます。
古いことわざは、「ロジックをコードに入れるか、データベースに入れるか」というものでした。最適な選択は要件に基づいています。アプリの主要な価値が「ユーザー定義フィールド」の概念に完全に柔軟である場合は、EAVを使用してください。ただし、その一方で、パフォーマンスに関しては、DBが適切にインデックス化されて構成されている場合、500万行は大した問題ではありません。私は、ヘルスケア業界で数億行のデータを持つアプリを管理しました。インデックス/構成が適切な場所にある場合、3億行でもすばやく機能します（バッチロードを除く:)）。チェックアウト https://en.wikipedia.org/wiki/Entity – attribute–value_model