在通常的資料庫設計中，我們定義了每個實體有多少個屬性，每個屬性的資料型別是什麼，有多長，是否允許為空，有什麼約束條件等，這些定義是完全靜態的，系統建立時就全部定義好，不能動態修改。但是對於實體的屬性變化很快，或者實體和屬性由使用者在系統中自行定義的情況下，那麼就需要一個可以動態擴充套件的資料庫模型，以儲存各種動態產生的資料。
比如我們要做一個電子商務網站，需要建立一個商品表以儲存各種要賣出的商品的屬性。但是商品的屬性各種各樣，不同類別的商品在屬性上千差萬別，不可能建立一個靜態的商品表來儲存所有的屬性。這個時候就需要建立動態的資料庫模型。
常見的動態擴充套件的資料庫設計方法有以下幾種：
一、以字串儲存各種資料型別，通過行轉列實現實體屬性讀取。
以前提到的電子商務網站的商品實體為例，我們可以建立兩個表“商品”和“商品屬性”，商品表為普通的商品屬性，可以將商品名稱、價格等大部分商品的公共屬性放到該表中。商品表與商品屬性表形成一對多關係，商品屬性表只需要定義商品“屬性名”和“屬性值”這兩個屬性用於儲存一個商品的各個屬性。
這樣在每讀取一個商品時，可以讀取該商品的屬性集合，然後將屬性集合重新繫結到物件，將該物件暫時在頁面上。
這種做法的優點是靈活，可以為商品建立無數個不同的屬性，可以應對電商這種快速變化，快速上線的需求。缺點是後期做統計的時候會很慢，因為需要行轉列，如果要涉及到各種Join查詢之類的也會很麻煩。
二、預定義大量的冗餘列，根據使用者對實體屬性的型別設定匹配對應的列。
如果我們不希望行轉列的話，那麼可以預先定義好資料列，由於不確定是哪種資料型別，所以我們可以將表的列定義的特別多，每個不同的資料型別都定義幾個或者十來個列，這些列都是允許為空的，如果沒有使用已經預定義好的列，並不會佔據多少資料空間。
在SharePoint 2007或者更早的版本中，對列表的資料儲存就是採用這種方式，以下是SharePoint2007中的AllUserData表的結構。基本上為每種資料型別定義了十來個到幾十個的列，使用者在建立不同的列表時，都可以使用這個表儲存列表資料。
這種資料庫設計方法的優點是不會存在行轉列的問題，所以在join或者出報表時效能較好，缺點就是使得一個表的列特別多，而且大部分列在大多數情況下是不使用的，而且擴充套件比較困難，比如我們要定義17個bit型別的列，但是系統預設只有16個，這種情況下，就需要在資料庫中使用2行資料來表示1行列表資料。
三、使用XML資料型別儲存動態列資料。
XML資料型別是SQL的一個標準，目前主流的資料庫都支援XML資料型別，資料庫為XML提供專門的語法以快速檢索和操作XML資料。在新版的SharePoint中，就使用XML來儲存使用者自定義列表的內容。
對於前面提到的商品表和商品屬性表，其實也可以只建立商品表，在該表中新增一XML型別的列，用於儲存商品的各種屬性。這是比較推薦的一種處理方法。
四、為使用者定義的實體動態建立表。
還有一直動態方法是在程式中動態建立表，使用者每在程式中定義一個實體的時候，就好根據使用者定義建立一個對應的表。比如微軟的Dynamic CRM就是這樣實現的。使用者可以在系統中建立大量的實體，並且還可以定義實體之間的關係，系統就會按照使用者的定義建立對應的表，以及外來鍵。
這種方法的優點是效能好，每個實體與其資料庫表相對應，不存在大量的冗餘列，也不會存在行轉列的問題。缺點是開發難度大，對使用者的要求高；而且在建立好實體並且儲存了大量資料後，如果想要修改實體屬性，那麼將很困難。