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