製品のデータベースで提供される標準のエンティティ スキーマにユーザーがカスタム フィールドを追加できるようにする方法が、今日また出てきました。私は実際にユーザーに制限付きの DDL 関数を提供する関数を提供することを好みます。これにより、ユーザーは実際に新しいカスタム フィールドをテーブルに追加できます。もう 1 つの方法は、Customers と CustomersEx などのカスタム フィールド用に別のテーブルを用意することです。ここでは、CustomersEx のみが変更できますが、ここでは更新が通常よりも難しくなります。私たちが議論した最後の最も悪いオプションは、行がエンティティ名、フィールド名、フィールド値である EAV テーブルを提供することでした。
どのアプローチが最適ですか?
既存のリレーショナル構造に追加される EAV。このトピックについては、SQL Server CAT (Customer Advisor Team) によって発行されたホワイトペーパーがあります。ベンダー固有ですが、説明した原則と提案されたソリューションは、ほとんどの RDBMS に適用されます:パフォーマンスとスケーラビリティのためのセマンティック データ モデリングのベスト プラクティス
私はあなたの 2 番目のアイデアを支持します。同様のことを行いますが、テーブルを Attr[ibute] テーブルと呼びます (例: Company、CompanyAttr)。属性はビジネス オブジェクト (1:M) のコレクションであり、NHibernate はデータベース操作を処理します。これらのフィールドは、UI で属性として明示的に表示され、テーブル内の追加フィールドであるかのように表示されません。
DDL を介してテーブルにフィールドを追加することを好みますが、そのテーブルはメイン テーブルとは別にする必要があります。これにより、ユーザーのカスタム フィールドの追加に影響を与えることなく、データベース スキーマへの変更をスクリプト化できます。右結合は簡単に実行でき、カスタム フィールドがなければ別のテーブルにレコードは必要ありません。
データを縦に並べて表示したい場合は、EAV テーブルが適しています。ピボット クエリを実行して、水平方向に表示することもできます。