カスタムフィールドとデータ型のデザインパターン/戦略
データオブジェクトにカスタムフィールドを追加する機能、またはオブジェクトの独自のカスタム定義を作成する機能を備えたアプリケーションを設計するための一般的な戦略または設計パターンはありますか？たとえば、独自のタイプの情報を持つことができるSalesForceなどの製品、式エンジンなどのフレームワーク、およびチャネルとチャネルフィールドグループの処理方法 （例） 、または方法CMSes Like wordpressには、カスタム投稿タイプにフィールドを追加する機能があります。
マーティン・ファウラーは、動的プロパティ（基本的にはあなたが求めているもの）をモデル化する方法を、彼の 本「分析パターン」 で素晴らしい説明をしました。ほとんどのコンテンツはPDFの記事としてオンラインで無料で入手できます。探しているのはこれです。
EAV model は通常、非構造化スキーマに使用されます。
パフォーマンスと、そのような動的なプロパティをアドホックな方法でクエリする能力が低下します。そのため、多くの人がアンチパターンと見なしています。
他のアプローチは、XMLやJsonなどの動的フォーマットを使用して、そのようなプロパティを保持することです。おそらく、検索を支援するために各プロパティに専用のストレージを使用します。
@Odedが説明するEAVテーブルに加えて、人々はこのタイプの情報にnosql datbaseを使用します。アプリケーションが、リレーショナルモデルで意味のある部分にリレーショナルデータベースを使用できず、そうでない情報にnosqlデータベースを使用できない理由はないことに注意してください。
3番目の可能性は、顧客が追加したフィールド（Customerfield1、customerfield2など）にいくつかの列を追加し、顧客にそれらの意味を定義してもらうことです。ただし、これは、追加する顧客が互換性のあるフィールドの数に対してのみ機能するため、2つまたは3つが必要であると予測しても問題はありませんが、数百が必要な場合はまったく機能しません。
UDF1、UDF2、UDF3などのテーブルを含む最初のアプリケーションはありません。他の提案（EVAまたはNoSQL）の方がはるかに優れています。
RDBMSによっては（ SQL Serverはこれを提供します ）、正規化から脱却して、XML形式またはプレーンテキストのみでデータを保持するフィールドを持つことができます。これを管理するには、コードに依存する必要があります。