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