既存の成熟したスキーマがあり、それにいくつかの新しいProduct属性を追加する必要があります。たとえば、Products.Flavorがあり、Weight、Fragranceなどの新しい属性を追加する必要があります。Productsテーブルを拡大し続けるのではなく、他のいくつかのオプションを検討しています。1つ目は、任意の属性のプロパティバッグとなる新しいAttributesテーブルと、特定の製品の属性のマッピング（および値）を格納するProductsAttributesテーブルです。私が理解するようになったので、これはEntity-Attribute-Value（EAV）パターンです。もう1つのオプションは、属性と呼ばれるXMLタイプのProductsテーブルに新しい列を追加することです。ここでは、新しいテーブルを追加せずに、任意の製品インスタンスに属性を任意に追加できます。
各アプローチの長所/短所は何ですか？SQLServer2008とASP.NET4.0を使用しています。
これは（私見）古典的なデータベース設計の問題の1つです。これを「属性クリープ」と呼びます。おそらく、開始すると、追加する別の属性またはプロパティが常に存在するためです。重要な決定は、データベースが提供する基本的なツール（テーブルと列）を使用してデータをデータベース内に格納し、データを構造化およびフォーマットするか、それとも他の方法（XMLと名前/値のペア）でデータを格納するかです。最も一般的な代替手段です）。簡単に言えば、DBMSシステムでサポートされている形式以外の形式でデータを保存すると、そのデータを管理、維持、および操作するためのDBMSシステムの能力が失われます。これは、「ブロブデータ」として保存するだけでよい場合（すべてをダンプし、すべてをポンプで排出する）はそれほど問題にはなりませんが、このデータを検索、並べ替え、またはフィルタリングする必要がある場合は、次のようになります。非常に醜い非常に速い。
そうは言っても、私は名前と値のペアとXMLについて強い意見を持っていますが、残念ながら、肯定的なものはありません。この方法でデータを保存する必要があり、それが完全に有効なビジネス/設計上の決定である可能性がある場合は、データベースに保存する必要のあるデータがどのように使用され、アクセスされるかをじっくりと検討することをお勧めします。将来。使用方法に照らして各方法論の長所と短所を比較検討し、管理と保守が最も簡単な方法を選択します。（実装が最も簡単なものを選択しないでください。作成するよりもずっと長くサポートすることになります。）
（長いですが、「RLH」エッセイは名前と値のペアがうまくいかない典型的な例です。）
（ああ、それを使用している場合は、SQL Server 2008の[スパース列]オプションを調べてください。必要なものとは思えませんが、わかりません。）