在通常的資料庫設計中，我們定義了每個實體有多少個屬性，每個屬性的資料類型是什麼，有多長，是否允許為空，有什麼限制條件等，這些定義是完全靜态的，系統建立時就全部定義好，不能動态修改。但是對于實體的屬性變化很快，或者實體和屬性由使用者在系統中自行定義的情況下，那麼就需要一個可以動态擴充的資料庫模型，以儲存各種動态産生的資料。
比如我們要做一個電子商務網站，需要建立一個商品表以儲存各種要賣出的商品的屬性。但是商品的屬性各種各樣，不同類别的商品在屬性上千差萬别，不可能建立一個靜态的商品表來存儲所有的屬性。這個時候就需要建立動态的資料庫模型。
常見的動态擴充的資料庫設計方法有以下幾種：
以前提到的電子商務網站的商品實體為例，我們可以建立兩個表“商品”和“商品屬性”，商品表為普通的商品屬性，可以将商品名稱、價格等大部分商品的公共屬性放到該表中。商品表與商品屬性表形成一對多關系，商品屬性表隻需要定義商品“屬性名”和“屬性值”這兩個屬性用于儲存一個商品的各個屬性。
這樣在每讀取一個商品時，可以讀取該商品的屬性集合，然後将屬性集合重新綁定到對象，将該對象暫時在頁面上。
這種做法的優點是靈活，可以為商品建立無數個不同的屬性，可以應對電商這種快速變化，快速上線的需求。缺點是後期做統計的時候會很慢，因為需要行轉列，如果要涉及到各種join查詢之類的也會很麻煩。
如果我們不希望行轉列的話，那麼可以預先定義好資料列，由于不确定是哪種資料類型，是以我們可以将表的列定義的特别多，每個不同的資料類型都定義幾個或者十來個列，這些列都是允許為空的，如果沒有使用已經預定義好的列，并不會占據多少資料空間。
在sharepoint 2007或者更早的版本中，對清單的資料存儲就是采用這種方式，以下是sharepoint2007中的alluserdata表的結構。基本上為每種資料類型定義了十來個到幾十個的列，使用者在建立不同的清單時，都可以使用這個表存儲清單資料。
這種資料庫設計方法的優點是不會存在行轉列的問題，是以在join或者出報表時性能較好，缺點就是使得一個表的列特别多，而且大部分列在大多數情況下是不使用的，而且擴充比較困難，比如我們要定義17個bit類型的列，但是系統預設隻有16個，這種情況下，就需要在資料庫中使用2行資料來表示1行清單資料。
xml資料類型是sql的一個标準，目前主流的資料庫都支援xml資料類型，資料庫為xml提供專門的文法以快速檢索和操作xml資料。在新版的sharepoint中，就使用xml來存儲使用者自定義清單的内容。
對于前面提到的商品表和商品屬性表，其實也可以隻建立商品表，在該表中添加一xml類型的列，用于存儲商品的各種屬性。這是比較推薦的一種處理方法。
還有一直動态方法是在程式中動态建立表，使用者每在程式中定義一個實體的時候，就好根據使用者定義建立一個對應的表。比如微軟的dynamic crm就是這樣實作的。使用者可以在系統中建立大量的實體，并且還可以定義實體之間的關系，系統就會按照使用者的定義建立對應的表，以及外鍵。
這種方法的優點是性能好，每個實體與其資料庫表相對應，不存在大量的備援列，也不會存在行轉列的問題。缺點是開發難度大，對使用者的要求高；而且在建立好實體并且存儲了大量資料後，如果想要修改實體屬性，那麼将很困難。