我目前正在设计大型SharePoint部署。
这种部署有可能在几年的时间内增长到PB级。
我们正在讨论的当前问题之一是使用InfoPath Forms在SharePoint中存储数据的选项。 其中某些形式包含数百个字段，并且需要大量映射到内容类型以进行持久性和搜索。 我们的搜索要求主要是单数标识符，而不是表格的内容，尽管我被告知我将来应该优先搜索“想要”。
我们要求将我们的信息用于其他目的（例如报告等）。 持久存储到系统后，必须立即可以访问该信息。
因此，我的核心问题是：
1.）
效益：
风险：
2）嗯，这是一个艰难的过程。 更改表单模板并重新部署很容易，只需几分钟。 但是，更改模板的结构（底层XML）会使您很麻烦，因为较旧的（已填写）表单将是无效的-有一个选项可以直接“升级”较旧的表单，但是根据我的经验，它从未达到预期的效果。
内容类型的行为非常相似，例如您要从内容类型中删除列，因为不再需要它-您必须删除对其的所有引用，这意味着删除所有项目，以便可以删除该列。
3.）良好的可移植性无疑是InfoPath的问题，因为它严重依赖于相应的URL结构。 您绝对可以添加更多网站集，但这意味着您必须将表单模板部署到每个网站集。 信息（填写的表单）很难在网站集之间共享，因为每种表单都包含SourceURL（它来自何处）和模板的命名空间（部署后会不断变化）。
考虑到您的需求，我强烈建议您使用关系存储而不是InfoPath-仅仅是因为它并非旨在作为数据存储。
我将使用SQL数据库存储数据，并使用自定义UI（WebPart或应用程序页面）执行CRUD操作。 这意味着信息实际上并没有存储在SharePoint中-只是显示了（这也意味着无法使用内置的SharePoint搜索来搜索信息）。 也可以使用Business Connectivity Services （基本上完成上述所有操作，而无需创建自定义UI，但是处理大量数据的速度非常慢）。
如果您确实需要SharePoint中的信息，为什么不只使用列表来实现所有这些功能呢？
这将是一个漫长的过程，可能只是因为找不到所需的解决方案而没有答案。 这主要是洞察力，最终选择取决于您。
使用InfoPath Forms在SharePoint中存储数据的选项
这句话使我有些惊讶。 SharePoint数据存储在SharePoint中（从技术上讲，是SQL），但是InfoPath只是用于访问该数据任何部分的UI层。
其中一些表单包含100多个字段，并且需要大量映射到内容类型以进行持久性和搜索
据此，我假设存在多种形式，这意味着将要访问不同类型的数据（并且可能具有不同的用途）。 数百个字段是没有问题的，它实际上可以归结为管理表单和视图设计。
从表单方面，您应该查看cxpartners 表单设计婴儿床表 。 这为您提供了一个很好的标准来管理所有这些字段。 另一件事是要根据用户需要填写的内容，在选项卡或视图本身（在InfoPath中）中分解表格。 从根本上讲，它可以分解为在一个巨大的滚动屏幕上不创建具有100个字段的表单的用户，而这简直就是吓呆了。
与将表单数据存储在表单或文档库中的视图相同。InfoPath表单只是存储在库中的xml（因此，无论您有多少字段，占用的空间都非常小）。 您既不想映射和显示表单中的每个字段，也不想拥有包含100列的视图。 您应该查看按用途划分的视图，每个视图只有几百个项目，只有几列。 这也是一种平衡的行为，因为您也不想创建100个视图，因此您需要找出正确的视图。 一个好的BA或Information Architect将在SharePoint / InfoPath专家和业务用户的帮助下帮助您。
我们要求将我们的信息用于其他目的（例如报告等）。 该信息必须立即可用
这是另一个要求，要完全满足它会有些困难。 如果库中有数千个项目（或成千上万个），并且一个视图有数十个字段，则希望该视图能够爬网（特别是如果用户坚持“查看所有内容”并希望设置每个视图的限制）到1000个项目，就像任何人都可以一次处理那么多信息一样。 如果您长时间将所有内容保持在线状态（例如进行报告），则难以即时访问。 在操作方面，用户正在填写表格，查找表格，对其进行编辑等，为此，您只希望在任何给定时刻可以使用几百个项目（最多几千个项目，但您需要在操作时多加小心）意见）。 如果您有一个包含100,000个项目的列表，并且用户正在使用该列表进行日常活动， 并试图针对该列表运行趋势或长期操作报告，那么您将失去性能之争。 看一下进行脱机报告，可能会将可报告的数据传送到第二个来源（如SQL），然后对它使用SSRS。 Performance Point是一个选项，但会给体系结构增加一层复杂性。 问题最终将落在报告的外观上，以及它相对于日常运营的重要性。
尝试直接回答您的问题：
在数据库上使用SharePoint的好处是可以轻松查看数据，对其进行切片和切块。 创建视图是孩子们的游戏，可以迅速向您显示有用的信息，例如一个月的销售数量或按呼叫中心人员分组的客户反馈。 通过SharePoint，可以轻松查看此信息，甚至可以设置仪表板，挂接KPI等，而无需让某些开发人员来制作自定义网页。 就风险而言，您需要小心谨慎，以使事情有机地增长并不受控制。 不要让用户设计数据视图，他们通常想要一些但不确定的东西，并且会要求所有列都可用，然后将它们导出到Excel中进行切片和切块。 确保视图和列表周围的设计良好，并且适合目的，并满足用户试图从数据中获取的需求。 询问他们正在寻找什么以及为什么的问题，这将有助于确定要曝光的内容。
任何变更都需要考虑，计划和测试。 如果将列添加到列表中，就像在SQL数据库中添加列一样，在SharePoint中也没有什么不同。 应该考虑更新表单，虽然您第一次不会100％正确，但是您应该尝试获得尽可能多的信息，而又不要过度投入，并放入诸如100个“空白”字段之类的疯狂东西，这些东西稍后将被命名。 。 通过了解用户和公司的需求以及前进的方向来取得平衡。 希望有人对它长大后会有什么看法，这将对理解变化的影响大有帮助。
数据只是xml，只要您不以诸如对服务的绝对路径进行硬编码（使用数据连接库）的形式进行愚蠢的工作，那么增长的影响就将很小。 从Web应用程序扩展到多个应用程序是一个相当大的变化，而且不要轻描淡写。 即使将网站集进行拆分也很大，因此确实有充分的理由。 网站集可以处理数千个网站和数百万个文档，而不会出现问题。 Web应用程序确实是用于划分感兴趣的区域或目的的区域（例如，一个Web应用程序上的团队站点和另一个Web应用程序上的发布门户），而并不是出于增长的考虑而真正用于拆分数据。
就像我说的，这里没有灵丹妙药，您要的是一种解决方案的体系结构，这里没有人有所有要求。 希望这可以帮助。