我目前正在構建大型SharePoint部署。支持大型表單的SharePoint InfoPath最佳實踐
此部署可能會在幾年內增長到PB級。
我們正在討論的當前問題之一是使用InfoPath表單將數據存儲在SharePoint中的選項。其中一些表單包含100個字段，並且需要大量映射到持久性和搜索的內容類型。我們的搜索要求主要是一個單一的標識符，而不是表格的內容，儘管我被告知我應該搶先「搜索」未來。
我們要求我們的信息被用於次要目的（如報告等）。信息必須在堅持系統後立即可用。因此
我的核心問題是：
1）
優點：可以創建
風險：
2.）那麼這是一個艱難的。更改表單模板並重新部署很簡單，只需要幾分鐘。但是，更改模板的結構（底層XML）會使您很容易陷入困境，因爲較舊（已填寫）的表單將無效 - 可以選擇「立即」升級舊錶單，但可以我的經驗從來沒有像預期的那樣工作。
內容類型的行爲非常相似，例如，您想從內容類型中刪除一列，因爲它不再需要 - 您必須刪除對它的所有引用，這意味着要刪除所有項目以便刪除該列。
3.）良好的可移植性是InfoPath的一個問題，因爲它很大程度上依賴於相應的URL結構。您絕對可以添加更多網站集，但這意味着您必須將表單模板部署到每個網站集。由於每個表單都包含SourceURL（它來自哪裏）和模板的名稱空間（部署後會不斷變化），因此信息（填寫的表單）不能在網站集之間輕鬆共享。
考慮您的要求，我會強烈建議關係存儲，而不是InfoPath中的 - 只是因爲它不是設計成一個數據存儲。
我會使用SQL數據庫來存儲數據和自定義UI（WebPart或Application Page）來執行CRUD操作。這意味着信息實際上並不存儲在SharePoint中 - 僅顯示（這也意味着無法使用內置SharePoint搜索進行搜索）。也有可能使用Business Connectivity Services（基本上不需要創建自定義用戶界面基本上完成上述所有操作，但對於大量數據非常緩慢）。
如果您確實需要SharePoint中的信息，那麼爲什麼不僅僅使用List來完成所有這些工作？
這將是一個漫長的，可能沒有答案只是因爲你沒有找到什麼銀彈。這主要是洞察力，最終選擇取決於你。
使用InfoPath存儲在SharePoint中我們的數據的選項窗口
本聲明拋出我一點點。 SharePoint數據存儲在SharePoint（技術上，SQL）中，但InfoPath只是用於訪問該數據任何部分的UI層。
有些形式包含字段的100S，需要很多映射到內容類型的持久性和搜索
從這我假設有多種形式這意味着在訪問不同類型的數據（並可能有不同的目的）。數百個領域是沒有問題的，它真的歸結爲管理窗體和視圖設計。
從表單方面你應該檢查cxpartners form design crib sheet。這給你一個很好的標準來管理所有這些領域。另一件事就是根據用戶需要填寫的內容，在標籤或視圖本身（在InfoPath中）中查看錶單。基本上，它打破了不在一個大規模滾動屏幕上創建一個具有100個字段的表單，用戶只會驚慌失措。
與您在窗體或文檔庫中存儲表單數據的視圖相同。InfoPath表單只是xml存儲在一個庫中（因此無論您擁有多少個字段，佔用空間都很小）。您不希望映射和顯示錶單中的每個字段，也不想在其上包含100列的視圖。您應該仔細分析視圖，因爲它們適合用途，每個視圖中只有幾百個項目，並且只有幾列。這也是一個平衡的行爲，因爲你不想創建100多個視圖，所以你需要找出什麼是正確的。好的B.A.或者信息架構師將幫助SharePoint/InfoPath專家和業務用戶提供幫助。
我們要求我們的信息被用於第二目的（如報告等）。信息必須立即可以訪問
這是另一個要求，有點難以準確地滿足。如果圖書館有數千個項目（或數千個），並且視圖有數十個字段，那麼期望視圖能夠抓取（特別是如果用戶堅持「看到所有東西」並且希望設置每個視圖的限制到1000個項目，就像任何人都可以一次處理那麼多信息一樣）。如果您將所有內容保持在線狀態很長一段時間（例如報告），即時訪問非常困難。用戶填寫表單，查找表單，編輯表單等操作方面都是非常重要的，因此您只需要在任何特定時刻生活幾百件物品（高達幾千件），但您需要小心視圖）。如果您有一個包含100,000個項目的列表，並且用戶正在將其用於日常活動和試圖針對趨勢或長期操作運行報告，則您將失去性能之戰。查看離線報告，可能將可報告的數據傳送到第二個來源，如SQL，並使用SSRS進行報告。性能點是一個選項，但會增加架構的一層複雜性。這個問題最終將歸結爲報告的內容以及它在日常運營中的重要性。
要嘗試直接回答你的問題：
到使用SharePoint在數據庫的好處是，可以將數據輕鬆地查看和切片和切塊起來。創建視圖是兒童遊戲，可以快速向您顯示有用的信息，如一個月內的銷售量＃或由呼叫中心人員分組的客戶反饋。 SharePoint可以輕鬆查看此信息，甚至可以設置儀表板，掛鉤KPI等，而無需讓某些開發人員製作自定義網頁。就風險而言，您需要小心讓事情有機地發展並失控。不要讓用戶設計數據視圖，他們通常想要的東西，但不知道，並會要求所有列可用，他們只是出口到Excel切片和骰子。確保圍繞視圖和列表有一個很好的設計，並且它們適合用途並滿足用戶試圖擺脫數據的需求。詢問他們在尋找什麼以及爲什麼，這將有助於確定要披露的內容。
任何變化都需要考慮並計劃和測試。如果將列添加到列表中，那麼在SharePoint中也沒有什麼不同，就像將列添加到SQL數據庫一樣。表格更新應該被考慮，雖然第一次你不會100％正確地獲得它，但你應該儘可能地儘可能地避免陷入尷尬境地，並且將100個「空白」字段放入瘋狂的東西， 。通過了解用戶和公司的需求以及事情的發展來實現平衡。希望有人能夠看到這個事情在成長過程中可能會發生什麼，這將對理解變革的影響有很大的幫助。
數據只是xml，只要你沒有像硬編碼的絕對路徑到服務（使用數據連接庫）那樣做愚蠢的東西，增長的影響將是最小的。從Web應用程序擴展到多個Web應用程序是一個非常大的改變，而不是輕率的事情。即使拆分網站集合很大，這需要有一個非常好的理由。網站集可以處理數千個網站和數百萬個文檔，而且沒有問題。 Web應用程序實際上是爲了劃分感興趣的領域或目的分離（例如，一個Web應用程序上的團隊站點和另一個Web上的發佈門戶），而不是真的意味着由於增長問題而拆分數據。
就像我說的，這裏沒有銀彈，你要求的是一個解決方案的體系結構，沒有人在這裏有所有的要求。希望這可以幫助。
SharePoint中的數據始終存儲在列表中。我知道，雖然量很大，但效果並不理想。 – GaryMcAllister