在通常的資料庫設計中，我們定義了每個實體有多少個屬性，每個屬性的資料型別是什麼，有多長，是否允許為空，有什麼約束條件等，這些定義是完全靜態的，系統建立時就全部定義好，不能動態修改。但是對於實體的屬性變化很快，或者實體和屬性由使用者在系統中自行定義的情況下，那麼就需要乙個可以動態擴充套件的資料庫模型，以儲存各種動態產生的資料。
比如我們要做乙個電子商務**，需要建立乙個商品表以儲存各種要賣出的商品的屬性。但是商品的屬性各種各樣，不同類別的商品在屬性上千差萬別，不可能建立乙個靜態的商品表來儲存所有的屬性。這個時候就需要建立動態的資料庫模型。
常見的動態擴充套件的資料庫設計方法有以下幾種：
一、以字串儲存各種資料型別，通過行轉列實現實體屬性讀取。
以前提到的電子商務**的商品實體為例，我們可以建立兩個表「商品」和「商品屬性」，商品表為普通的商品屬性，可以將商品名稱、**等大部分商品的公共屬性放到該表中。商品表與商品屬性表形成一對多關係，商品屬性表只需要定義商品「屬性名」和「屬性值」這兩個屬性用於儲存乙個商品的各個屬性。
這樣在每讀取乙個商品時，可以讀取該商品的屬性集合，然後將屬性集合重新繫結到物件，將該物件暫時在頁面上。
這種做法的優點是靈活，可以為商品建立無數個不同的屬性，可以應對電商這種快速變化，快速上線的需求。缺點是後期做統計的時候會很慢，因為需要行轉列，如果要涉及到各種join查詢之類的也會很麻煩。
二、預定義大量的冗餘列，根據使用者對實體屬性的型別設定匹配對應的列。
如果我們不希望行轉列的話，那麼可以預先定義好資料列，由於不確定是哪種資料型別，所以我們可以將表的列定義的特別多，每個不同的資料型別都定義幾個或者十來個列，這些列都是允許為空的，如果沒有使用已經預定義好的列，並不會佔據多少資料空間。
在sharepoint 2007或者更早的版本中，對列表的資料儲存就是採用這種方式，以下是sharepoint2007中的alluserdata表的結構。基本上為每種資料型別定義了十來個到幾十個的列，使用者在建立不同的列表時，都可以使用這個表儲存列表資料。
這種資料庫設計方法的優點是不會存在行轉列的問題，所以在join或者出報表時效能較好，缺點就是使得乙個表的列特別多，而且大部分列在大多數情況下是不使用的，而且擴充套件比較困難，比如我們要定義17個bit型別的列，但是系統預設只有16個，這種情況下，就需要在資料庫中使用2行資料來表示1行列表資料。
三、使用xml資料型別儲存動態列資料。
xml資料型別是sql的乙個標準，目前主流的資料庫都支援xml資料型別，資料庫為xml提供專門的語法以快速檢索和操作xml資料。在新版的sharepoint中，就使用xml來儲存使用者自定義列表的內容。
對於前面提到的商品表和商品屬性表，其實也可以只建立商品表，在該表中新增一xml型別的列，用於儲存商品的各種屬性。這是比較推薦的一種處理方法。
四、為使用者定義的實體動態建立表。
還有一直動態方法是在程式中動態建立表，使用者每在程式中定義乙個實體的時候，就好根據使用者定義建立乙個對應的表。比如微軟的dynamic crm就是這樣實現的。使用者可以在系統中建立大量的實體，並且還可以定義實體之間的關係，系統就會按照使用者的定義建立對應的表，以及外來鍵。
這種方法的優點是效能好，每個實體與其資料庫表相對應，不存在大量的冗餘列，也不會存在行轉列的問題。缺點是開發難度大，對使用者的要求高；而且在建立好實體並且儲存了大量資料後，如果想要修改實體屬性，那麼將很困難。
可動態擴充套件的資料庫模型設計
在通常的資料庫設計中，我們定義了每個實體有多少個屬性，每個屬性的資料型別是什麼，有多長，是否允許為空，有什麼約束條件等，這些定義是完全靜態的，系統建立時就全部定義好，不能動態修改。但是對於實體的屬性變化很快，或者實體和屬性由使用者在系統中自行定義的情況下，那麼就需要乙個可以動態擴充套件的資料庫模型，...
mysql 資料庫字段動態擴充套件
主要有一下幾種方案 當資料庫中需要增加乙個欄位的時候，直接在資料庫中增加，並修改相應的 優點 操作簡單，易懂 缺點 每增加乙個欄位都需要修改資料庫表結構，修改 而且在一張大表進行操作的時候，還可能需要很長時間。把需要擴充套件的字段統一放到乙個字段裡面。各個字段通過json的方式組成乙個大的字串。這樣...
資料庫模型設計 表設計
曾經何時，發現自己設計的表，根本不滿足業務發展。1.業務id的設計，如商品表，單錶就不說了，在如今海量資料的背景下，當然要分庫發表啦。商品表，id,item id,表位置，id當然就是主鍵了，在單錶情況下，保持唯一就可以。item id商品id，就是要在全域性保持唯一，可能商品表有30張，甚至100...