我正在設計自定義SharePoint應用程序的過程中。在之前的項目中，所有數據都保存在SharePoint列表中，這就是我現在一直在嘗試的方式。但是，我已經到了數據模型增長的階段，我覺得有必要對它進行規範化並將一個邏輯實體分成幾個物理列表。我想知道是否應該從SP列表切換到經典數據庫。一方面，我很滿意SharePoint的開箱即用新建項目，編輯項目，所有項目表單;另一方面，我擔心一旦我必須查詢連接的數據（如果它保持在SPList s），性能將受到影響。
如果您對此問題有任何洞察或經驗，請分享。謝謝。SharePoint：我應該使用列表還是數據庫？
這取決於你的需求，但是從我的經驗在這裏是當你應該使用名單的數據庫的情況：
1）當你在你的數據庫模型中的許多一對多的關係
2）當您有兩個或多個實體鏈接在一起時（例如，客戶>發票>發票產品）。
SharePoint很棒，但在上述情況下，您將遇到SharePoint UI限制的問題。 3）如果你打算有任何自定義報告或圖表，你應該堅持自己的數據庫。
當您使用數據庫實體時，最好的方法是開發自己的Web部件，因爲BDC在大多數情況下價格昂貴而且非常有限。您還可以檢查第三方網站部分（例如竹Web部件）
下面是對數據庫使用SharePoint列表的原因：
如果你有複雜的查詢，我建議你把它們放到一個單獨的數據庫中。當數據模型不經常增長時，列表是很好的。
擴展列表中列的字段數量包括直接用必須編碼的STSADM更新ContentType。但是，直接從數據庫查詢數據（當然有一些緩存）將導致更快的開發，而無需更新鏈接到與其關聯的每個列表的所有ContentType。
當然，如果激活緩存，則從數據庫查詢的數據將緩存在頁面輸出級別。
我想添加一個旁註說，搜索將不會是一個問題，因爲爬蟲爬網站而不是數據庫。我還可以告訴你，你可以將代碼綁定到列表的事件（添加，編輯，刪除），並讓他們在這些事件上執行代碼。真的很酷，可以同步一切。 – 2008-10-31 11:43:56
除了馬克西姆的答案，我還建議你考慮考慮。如果這些數據將成爲您需要深入研究的內容，那麼OTB Search非常好。
我不會太擔心去數據的自定義數據庫。
這確實意味着有額外的工作來使用自定義控件對它進行皮膚處理，並將這些控件引入佈局頁面和/或列表爲您做的自定義Web部件。
如果您有BDC可用，那將是要走的路，否則是自定義的。
因此，最終它是與易於與共享點集成並具有可用數據輸入表單與編碼所有這些項目，但完全控制數據完整性之間的折衷。
我同意使用數據庫的原因，但不一定是使用SharePoint列表的原因。 使用BDC（如果您有MOSS），如果您的數據存儲在外部數據庫中，並且可以在SharePoint中單獨訪問或與列表結合使用，則可以實現其中的許多功能。 – elorg 2009-06-23 13:51:26