SharePoint 数据策略
SharePoint Data Strategy
我们的组织希望使用 SharePoint Online 作为成熟文档管理系统的基础迁移到云。然而，我们正在努力将我们的组织结构映射到 SharePoint，并且想知道我们是否会遇到 SharePoint 的限制。
本质上，我们有一个董事会，它使用中央 "case" 列表来组织和管理其工作。列表中有数千个案例（可追溯到几十年前），并且每周新增约 10 个案例。然后有几个部门，每个部门负责创建、分析和管理一些案例，但有严格定义的权限，每个部门的员工组只能查看和处理与其相关的案例。因此，我们可能最多可以定义 10 个不同的安全组，可以向其中添加个人。同样，新董事会成员比选举时间更早地访问某些历史案件。
所有这些似乎都构成了一个复杂的场景，需要大量使用 "case" 列表中的项目级权限，而 SharePoint 在线显然有 5,000 个上限。
对于我们的思考过程以及 SharePoint 对我们手头场景的适用性的任何建议，我们将不胜感激。
非常感谢。
您好 Kia，感谢您分享您的挑战，
一个简单的计算让我相信，当谈论几十年的案例并假设每周 10 个新案例的恒定速率时，我们可能会谈论大约 ca。目前10 000例，每年增加约500例。我还假设当您提到案例列表时，您也将其表示为文字 SharePoint 列表。你没有提到的是每个安全组的人数——你设定的 10 人。 SharePoint 在每个安全范围上还有一个 2000 名成员 "limit" - 因此即使您对每个项目都有单独的权限，您仍然必须让所有用户至少具有 有限访问权限 权限。
所以我的建议是：
如果总共有超过 2000 人需要访问权限（请记住，通常不会手动从权限列表中删除老员工）或者如果您认为将达到甚至超过 5000 个单独的 ACL - 考虑将列表拆分为两个（或更多）Web 或两个网站集中 -> 我将它们称为当前和存档，但您可以根据需要每年或 5 年等进行存档。考虑使用 PowerShell script/Event handler/Workflow 等自动执行此操作。这样您将自动限制安全主体（即用户或组）的数量。不要害怕多个 Web 甚至网站集，而是尽可能多地使用网站集。确保以这样一种方式拆分它，即当达到特定限制时，较旧的条目会自动移动。示例：用户限制或单个 ACL 条目 - 您可以使用自定义计时器作业/Webhook 或脚本或定期使用的内容来确定。
在实施上述之后 - 我感受到了你的痛苦，你可能正在使用自定义 code/workflows 来创建案例并且你正在考虑 "OMG, just changing all the instances to adapt to the new architecture is going to take a long time!" - 但这当然取决于这部分的表现该系统已实施。既然您有多个网站或网站集，您仍然需要一种仪表板，您可以在其中查看和查找所有案例。我强烈推荐 基于搜索的解决方案 因为搜索服务非常强大，甚至可以（请参阅混合搜索）跨越在线和本地场。这应该相对容易实现，因为您可能已经为您的案例定义了自定义内容类型 - 因此只需在所有档案和当前案例位置上创建一个自定义搜索范围，然后使用它来执行 "Daily Work"。搜索服务可识别 ACL，并且没有列表视图所具有的限制。
简而言之：使用达到特定阈值时自动创建（分段）的网站或网站集 - 将其视为您的存储后端。然后使用自定义搜索范围 + Site/Search 中心来公开您的案例项目（前端）。
如果我可以提供进一步的提示或帮助，请告诉我。
我还推荐 Microsoft 的这个很好的例子，以从新的角度了解您的权限架构：MS Docs - Troubleshoot common fine grained permissions issues - 您将需要 1-2 杯咖啡，但这是值得的。
我们的组织希望使用 SharePoint Online 作为成熟文档管理系统的基础迁移到云。然而，我们正在努力将我们的组织结构映射到 SharePoint，并且想知道我们是否会遇到 SharePoint 的限制。
本质上，我们有一个董事会，它使用中央 "case" 列表来组织和管理其工作。列表中有数千个案例（可追溯到几十年前），并且每周新增约 10 个案例。然后有几个部门，每个部门负责创建、分析和管理一些案例，但有严格定义的权限，每个部门的员工组只能查看和处理与其相关的案例。因此，我们可能最多可以定义 10 个不同的安全组，可以向其中添加个人。同样，新董事会成员比选举时间更早地访问某些历史案件。
所有这些似乎都构成了一个复杂的场景，需要大量使用 "case" 列表中的项目级权限，而 SharePoint 在线显然有 5,000 个上限。
对于我们的思考过程以及 SharePoint 对我们手头场景的适用性的任何建议，我们将不胜感激。
非常感谢。
您好 Kia，感谢您分享您的挑战，
一个简单的计算让我相信，当谈论几十年的案例并假设每周 10 个新案例的恒定速率时，我们可能会谈论大约 ca。目前10 000例，每年增加约500例。我还假设当您提到案例列表时，您也将其表示为文字 SharePoint 列表。你没有提到的是每个安全组的人数——你设定的 10 人。 SharePoint 在每个安全范围上还有一个 2000 名成员 "limit" - 因此即使您对每个项目都有单独的权限，您仍然必须让所有用户至少具有 有限访问权限 权限。
所以我的建议是： 如果总共有超过 2000 人需要访问权限（请记住，通常不会手动从权限列表中删除老员工）或者如果您认为将达到甚至超过 5000 个单独的 ACL - 考虑将列表拆分为两个（或更多）Web 或两个网站集中 -> 我将它们称为当前和存档，但您可以根据需要每年或 5 年等进行存档。考虑使用 PowerShell script/Event handler/Workflow 等自动执行此操作。这样您将自动限制安全主体（即用户或组）的数量。不要害怕多个 Web 甚至网站集，而是尽可能多地使用网站集。确保以这样一种方式拆分它，即当达到特定限制时，较旧的条目会自动移动。示例：用户限制或单个 ACL 条目 - 您可以使用自定义计时器作业/Webhook 或脚本或定期使用的内容来确定。
在实施上述之后 - 我感受到了你的痛苦，你可能正在使用自定义 code/workflows 来创建案例并且你正在考虑 "OMG, just changing all the instances to adapt to the new architecture is going to take a long time!" - 但这当然取决于这部分的表现该系统已实施。既然您有多个网站或网站集，您仍然需要一种仪表板，您可以在其中查看和查找所有案例。我强烈推荐 基于搜索的解决方案 因为搜索服务非常强大，甚至可以（请参阅混合搜索）跨越在线和本地场。这应该相对容易实现，因为您可能已经为您的案例定义了自定义内容类型 - 因此只需在所有档案和当前案例位置上创建一个自定义搜索范围，然后使用它来执行 "Daily Work"。搜索服务可识别 ACL，并且没有列表视图所具有的限制。
简而言之：使用达到特定阈值时自动创建（分段）的网站或网站集 - 将其视为您的存储后端。然后使用自定义搜索范围 + Site/Search 中心来公开您的案例项目（前端）。
如果我可以提供进一步的提示或帮助，请告诉我。
我还推荐 Microsoft 的这个很好的例子，以从新的角度了解您的权限架构：MS Docs - Troubleshoot common fine grained permissions issues - 您将需要 1-2 杯咖啡，但这是值得的。