カスタムフィールドとデータ型の設計パターン/戦略

データオブジェクトにカスタムフィールドを追加する機能を持つオブジェクトを設計するための、またはオブジェクトの独自のカスタム定義を作成するための一般的な戦略または設計パターンはありますか。たとえば、独自の種類の情報を持つことができるSalesForceなどの製品、Expression Engineなどのフレームワーク、およびチャネルとチャネルフィールドグループの処理方法（例）、またはwordpressのようなCMSの機能カスタム投稿タイプにフィールドを追加します。

Martin Fowlerは、彼の著書 "Analysis patterns"で、動的プロパティ（基本的にはあなたが求めているもの）をモデル化する方法を説明しています。ほとんどのコンテンツは、PDFの記事としてオンラインで無料で入手できます。探しているのは次の記事です。

http://martinfowler.com/apsupp/properties.pdf

EAVモデルはあなたが説明するように、通常、非構造化スキーマのために使用されています。

それはパフォーマンスとそのような動的プロパティをアドホックな方法でクエリする能力に苦しみます...そしてそれ自体は多くの人がアンチパターンであると考えています。

他のアプローチとしては、XMLやJsonなどの動的形式を使用してそのようなプロパティを保持し、場合によっては検索を支援するために各プロパティ専用のストレージを使用します。

@Odedが説明するEAVテーブルに加えて、人々はこのタイプの情報にnosql datbaseを使用します。アプリケーションが、リレーショナルモデルで意味のある部分にはリレーショナルデータベースを使用できず、そうでない情報にはnosqlデータベースを使用できない理由はないことを思い出してください。

3番目の可能性は、顧客が追加したフィールド（Customerfield1、customerfield2など）にいくつかの列を追加し、顧客にその意味を定義させることです。これは、追加する顧客のcomnfiguarbleフィールドの数に対してのみ機能するため、2つまたは3つしか必要としないが数百が必要な場合はまったく機能しないと予想される場合は問題ありません。

UDF1、UDF2、UDF3を含むテーブルを持つ最初のアプリケーションはありません。他の提案（EVAまたはNoSQL）ははるかに優れています。

RDBMSに応じて（SQL Serverがこれを提供します）、正規化から抜け出し、XML形式または単なるテキストのデータを保持するフィールドを持つことができます。これを管理するには、コードに依存する必要があります。