1
最終的に構成可能なデータ駆動型のアプリケーションを設計したいと考えています。柔軟で設定可能な属性のSQLモデル
各ユーザーは、自分のフォームに表示されるフィールドをカスタマイズし、新しいフォームタイプを設定してさまざまなデータセットを収集することができます。
はあるユーザが必要になる場合があります。
- 名前
- 連絡先電話番号
- メール
は、別のユーザーが必要になることがあります。
- 名前
- 組織
- 住所
私は**エンティティ値（EAV）の属性**デザインパターンは、このために適切かもしれませんが、私の場合は基本的にすべてのフィールドが最初に知られるように予定されていると聞きました。新しいフィールドタイプは後で追加することができますが、制御されたプロセスになります。
〜1000の列のSQLテーブルを使用するのと比較して、EAVデザインパターンを使用する利点はありますか？各ユーザーは、要件に応じて列のオン/オフを切り替えることができますか？ EAVは単一のテーブルに比べてクエリの欠点がありますか？
もう1つのアプローチはありますか？
私は現在、正確にこれを実装する状況にあります。多くはないが非常に異なるフィールド（あらかじめわかっていない）を持つ、自由に定義可能なフォームです。私がEAVを使用する主な理由は、固定された列の膨大な量に対処したくないということです。顧客は、開発者として私があらゆる新しい分野に関わることを望まないのです。遅く進化するプロセス（時には関与したいところ）では、私は固定列の使用を検討します。 EAVの欠点は、関係するいくつかの結合とより悪いパフォーマンスで値を保存し検索する比較的複雑な方法です。 – IngoB
@IngoB洞察力のおかげで、EAVは当初は将来の柔軟性を考慮していましたが、当初は有限量のドメイン固有のフィールドであるため、私のユースケースでは最適ではないようです。 – J3Y