其中一個選項是EAV模型(實體 - 屬性 - 值)。
這種模式是好的,如果你在你的領域,一個類將導致寬表,表表示(大量列,許多空值)
它最初設計用於醫療領域應用,對象可能有數千個列(sympthoms)。
基本上你
實體(ID)(例如你的產品表) 屬性(ID,的ColumnName) 值(ENTITYID,屬性ID,值)
你可以有一些額外的元數據表。
值應該最好是多個表,一個類型。 例如: ShortStringValue(EntityId,AttributeId,Value nvarchar(50)); LongStringValue(EntityId,AttributeId,Value nvarchar(2048)); MemoValue(EntityId,AttributeId,Value nvarchar(max)); IntValue(EntityId,AttributeId,Value int);
甚至是一個補碼類型: ColorComponentsValue(EntityId,AttributeId,R int,G int,B int);
根據我的經驗,其中一件事是你不應該對所有東西都有EAV。例如,爲一個班級提供EAV。 如果您必須對不同的基類使用可擴展性,請讓它成爲一組獨立的EAV表。
另一件事是你必須爲你的對象發明一個智能實現策略。 不要將這些值轉換爲寬行集合,只爲您的查詢條件需要轉換少量的collumns,然後爲每個選定對象返回一個窄行集合的Value行。否則,pivoting會涉及大量連接。
有幾點需要考慮: 。每個值都需要外鍵的存儲空間 。例如,對於此類查詢,行級鎖定的行爲會有所不同,這可能會導致性能下降。 。可能會導致更大的指數大小。
實際上,在一個淺層世界的測試中,我的EAV解決方案在查詢中的20列表格上的表現優於其靜態對應表,其中4列涉及標準。
您的意思是說當您說可擴展時可擴展? – 2009-12-25 08:21:14