我有一個現有的成熟模式，我們需要添加一些新的產品屬性。例如，我們有Products.Flavor，現在需要添加新的屬性，例如Weight，Fragrance等。我不考慮繼續擴大Products表格，而是考慮其他一些選項。首先是一個新的屬性表，它將有效地作爲任意屬性的屬性包，以及一個ProductsAttributes表，用於存儲特定產品屬性的映射（和值）。這是實體 - 屬性 - 值（EAV）模式，我已經瞭解它。另一種選擇是向名爲Attributes的Products表添加一個新的列，該表是XML類型。在這裏，我們可以任意添加屬性到任何產品實例而無需添加新表格。實體屬性值（EAV）與XML列對於新產品屬性
每種方法的優缺點是什麼？我正在使用SQL Server 2008和ASP.NET 4.0。
這是（imho）經典數據庫設計問題之一。也許，稱它爲「屬性蔓延」，因爲一旦你開始，總會有另一個屬性或屬性添加。他們的關鍵決定是，是否使用數據庫提供的基本工具（表和列）將數據存儲在數據庫中以構建和格式化數據，還是以其他方式（XML和名稱/值對）存儲數據是最常見的替代品）。簡而言之，如果您以非DBMS系統支持的形式存儲數據，那麼您將失去DBMS系統管理，維護和處理數據的能力。如果您只需要將其存儲爲「blob數據」（將其全部轉儲，全部抽出），那麼這不是什麼大問題，但是一旦您開始必須通過此數據進行查找，排序或過濾，它可能會得到非常快，非常難看。有了這個說法，我對名稱/值對和XML有很強烈的意見，但唉，沒有一個是正面的。如果您必須以這種方式存儲您的數據，並且是可以是完全有效的業務/設計決策，那麼我會建議您長時間努力尋找如何使用和訪問您需要存儲在數據庫中的數據在將來。根據將如何使用每種方法來衡量利弊，並挑選最容易管理和維護的方法。 （不要挑選最容易實現的那個，你會支持它的時間比你寫的要長得多。）
（它很長，但the "RLH" essay是一個典型的名稱/值對的例子橫行。）
（哦，如果你使用它，看看SQL Server 2008中的「稀疏列」選項。聽起來不像你需要什麼，但你永遠不知道。）
感謝您的反饋。實際上，我們剛剛在這個主題上舉行了一次小型會議，並且因爲您列出的許多原因而決定使用表格而不是XML。現在只需要負責使用EAV模式。 – 2011-03-21 18:39:10
（Bookarking現在這個問題，所以我可以稍後再回來，upvote所有的「你真的不想這樣做」的答案） – 2011-03-21 14:25:28
這兩個選項中，我真的不想做的是哪一個？ ;-) – 2011-03-21 14:26:40
將新列添加到產品表時出現什麼問題？這些屬性僅與產品的某個子集相關嗎？ – tster 2011-03-21 14:48:42