我们开始使用SharePoint 2013来管理我们部门的流程文档，并且我对网站结构的最佳实践有一些疑问 . 我有点惊讶我无法通过网络搜索找到答案，因为这似乎是每个新的SharePoint用户必须处理的基本问题 .
从文件共享环境迁移，我正在努力摆脱这种心态，我理解SharePoint对文件共享的诸多好处 . 我也理解为什么在SharePoint中创建文件夹会强制文件上的任意分区，而一组带有元数据的大型文档可以根据不同的需要对文件进行过滤和分组 .
令我感到困惑的是，我还读到，拥有太多的子站点比使用它们更好 . 看起来子站点很容易变成伪文件夹，我不确定该行是哪里划过的 .
这是一个例子 .
我们有一个专门针对我们部门的SharePoint网站 . 我们创建了一个专门用于我们开发的应用程序的子站点，以便将数据加载到我们的业务系统中 . 它主要包含有关应用程序的技术文档 . 此应用程序支持许多不同的数据源，每个数据源都有自己的一组用户加载指令，自己的日程安排（日历），联系人列表，支持文件等 . 没有令人信服的理由将它们分开来限制访问 . 但是，将它们全部放在同一个子站点中似乎没什么 Value ，因为从事某项工作的人只想查看该数据源的文档和支持文件 . 我无法预见有人想要查看所有数据源中的支持文件，但是，我可以看到有人想要查看所有数据源的时间表 .
我的问题是，我应该在应用程序下为每个数据源创建单独的子站点，还是只将所有内容存储在应用程序子站点中，并使用元数据和视图按数据源对事物进行分组？将特定数据源的所有项目放入其自己的子站点似乎管理和呈现要比为每个新文件指定元数据和创建大量视图要简单得多 . 但是，我无法摆脱我仍在使用文件共享思维的感觉 . 或许我只是缺少一些SharePoint的基本概念 .
任何有关该主题的良好讨论的建议或链接将不胜感激 . 谢谢 .
1 回答
我建议您使用元数据和视图来分隔一个存储库/站点中的数据 .
我的理由如下：
在SharePoint中，建议使用元数据而不是“邪恶”文件夹（或您的案例中的子网站） . 请记住，维护多个子网站需要长期的大量管理工作，例如，某些网站将被继承而其他网站将获得独特的许可 .
随着时间的推移和人们的轮换，数据存储的位置和新数据应该去的位置变得模糊，特别是对于大量的子网站 .
由于保密性与您的情况无关，因此保持数据集中并向相关领域的工作人员开放，增加共享和协作现象 . 相反，使用子网站增加了数据孤岛的可能性 .
人都懒惰:) . 以我为例，我不想记住所有这些xyz网址，我想去一个地方并能够获取我需要的所有内容 .