ユーザーがカスタム フィールドを追加できる一般的なエンティティ (記事、ページ、ノードなど) があるアプリケーションを構築する必要があります。
最も人気のある php CMS (wp、drupal) がこの目標を達成するために使用するアプローチを見てきました。これらはすべて、最小限のフィールド (タイトルと本文など) を含むベーステーブルを持ち、他のすべてのフィールドを他のテーブルに委任します。次に例を示します。
table node
id | title | body
table field_foo
node_id | field_type | field_value
table field_bar
node_id | field_type | field_value
// and so on
これは、完全な mvc 環境ではかなり論理的です。フィールドコントローラーは、すべてのフィールドを個別に処理します。
しかし、パフォーマンスについて言えば、単一のノードをロードするには、多くのクエリまたは多くの結合が必要になります。
私は別のアプローチを取りました (私のアプリが基本フィールドを提供していない場合でも): すべてのフィールドについて、生の値を格納する新しい列をベース テーブルに追加し、それを必要とするすべてのフィールドのテーブルを追加します (複数のたとえば、フィールド、または他のエンティティへの参照) と、インデックスのみを持つ関係テーブル。field_id (そのテーブルは、バージョン管理とエンティティ間の関係の種類を追跡するため、実際には他の種類のジョブを実行します)
したがって、単一のクエリでエンティティからすべての生データを取得すると、フィールド コントローラーは (必要に応じて) そのフィールドの実際の値をロードする方法と場所を認識します。
データテーブル (table_entity_data)の列の型は、フィールド データの最適な推測です。テキストの場合はテキスト、小数の場合は小数です。複数のフィールド（そのテーブルの外に値がある）のみが配列です（実際の data_type は _field_foo_value.entity_value_ 列にあります）
エンティティ構造が頻繁に変更されないと仮定して、構造を正規化しようとしました..
他の大きなプロジェクトがこれを非常に異なる方法で処理することを考えると、私は自分の実装に疑いを持ち、私のハイブリッド構造でどのような問題が発生するのか疑問に思っています:
table entity
id
table entity_data
entity_id | field_foo_rav_value | field_bar_raw_value
table relations
entity_id | entity_field_id | field_id_value
table field_foo_value
field_value_id | entity_value
// lets say field_bar is a single text field, there no will be another table:
// entity_data.field_bar_raw_value contains the real value
なにか提案を？
ps: この質問は親切に一般的なものであることは承知しています。適切でない場合は、お気軽に終了のフラグを立ててください。