實體屬性值數據庫與嚴格關系模型電子商務可以肯定地說，Eav/CR數據庫模型不好。盡管如此，問題：應該使用什么數據庫模型、技術或模式來處理描述在運行時可以更改的電子商務產品的屬性的“類”？在一個良好的電子商務數據庫中，您將存儲各種選項(比如電視分辨率，然后每個電視都有一個分辨率，但下一個產品可能不是電視，也沒有“電視解析度”)。如何存儲它們，有效地搜索，并允許用戶使用描述其產品的可變字段設置產品類型？如果搜索引擎發現客戶通常根據控制臺深度搜索電視，則可以在字段中添加控制臺深度，然后在運行時為每個TV產品類型添加一個深度。在優秀的電子商務應用程序中，有一個很好的共同功能，它們顯示一組產品，然后有“向下”的側菜單，你可以看到“電視分辨率”作為標題，以及最常見的五種電視解析度。單擊其中一個，它只顯示該分辨率的電視，通過在側菜單上選擇其他類別，可以進一步向下鉆取。這些選項將是在運行時添加的動態產品屬性。進一步討論：長話短說，是否有任何鏈接在互聯網或模型描述，可以“學術上”修復以下設置？我感謝諾埃爾肯尼迪提出了一個類別表，但可能需要更多。下面我用不同的方式來描述它，試圖強調它的意義。我可能需要一個觀點修正來解決這個問題，或者我可能需要深入到Eav/CR。喜歡對Eav/CR模型的積極反應。我的同事們都說了JeffreyKemp在下面提到的：“新的實體必須由專業人員建模和設計”(脫離上下文，閱讀下面的回應)。問題是：實體每周添加和刪除屬性(搜索關鍵字指定未來屬性)新實體每周抵達(產品由零件組裝)舊實體每周離開(存檔，不那么受歡迎，季節性)客戶想要向產品添加屬性有兩個原因：部門/關鍵詞搜索/同類產品比較圖表結帳前的消費品配置屬性必須有意義，而不僅僅是關鍵字搜索。如果他們想比較所有“生奶油霜”的蛋糕，他們可以點擊蛋糕，點擊生日主題，點擊生奶油糖霜，然后檢查所有有趣的蛋糕，知道他們都有生奶油糖霜。這并不是蛋糕的特例，只是一個例子。