我应该使用 SharePoint 子站点还是元数据?

Should I be using SharePoint sub-sites or metadata?

我们开始使用 SharePoint 2013 来管理我们部门的流程文档,我对网站结构的最佳做法有一些疑问。我有点惊讶我无法通过网络搜索找到答案,因为这似乎是每个 SharePoint 新用户必须处理的基本问题。

离开文件共享环境后,我正在努力摆脱这种心态,并且我了解 SharePoint 相对于文件共享的诸多好处。我也理解为什么在 SharePoint 中创建文件夹会强制对文件进行任意划分,而一大组带有元数据的文档允许您根据不同的需要过滤和分组文件。

让我感到困惑的是,我还读到说子站点太多总比不够好。似乎子站点很容易变成伪文件夹,我不确定那条线在哪里越过。

举个例子。

我们有一个专门针对我们部门的 SharePoint 网站。我们创建了一个子站点,专用于我们开发的用于将数据加载到我们的业务系统中的应用程序。它主要包含有关应用程序的技术文档。此应用程序支持许多不同的数据源,每个数据源都有自己的一组用户加载说明、自己的日程安排(日历)、联系人列表、支持文件等。没有令人信服的理由将它们分开以限制访问。但是,将它们都放在同一个子站点中似乎也没有太多价值,因为从事某项工作的人只想查看该数据源的文档和支持文件。我只是无法预见有人想要查看所有数据源的支持文件,尽管如此,我可以看到有人想要查看所有数据源的合并时间表。

我的问题是,我应该在应用程序下为每个数据源创建单独的子站点,还是只将所有内容存储在应用程序子站点中并使用元数据和视图按数据源对事物进行分组?将特定数据源的所有项目放入其自己的子站点似乎比必须为每个新文件指定元数据并创建大量视图更易于管理和呈现。但是,我无法摆脱我仍在使用文件共享思维的感觉。或者我可能只是缺少 SharePoint 的一些基本概念。

任何关于此主题的良好讨论的建议或链接都​​将不胜感激。谢谢。

我建议您使用元数据和视图将数据合二为一repository/site。

我的理由如下:

  1. 在 SharePoint 中,建议使用元数据而不是 "evil" 文件夹(或您的子站点)。请记住,维护 从长远来看,多个子站点需要大量的管理工作, 例如,一些站点将被继承,而另一些站点将是唯一的 允许。

  2. 岁月流转人轮回变得模糊 数据存储在哪里以及新数据应该去哪里, 特别是对于大容量子站点。

  3. 由于您的案例不涉及机密性,因此保持数据集中并向相关领域的工作人员开放会增加共享和协作现象。相反,使用子站点会增加数据孤岛的可能性。

  4. 人都是懒惰的:)。以我为例,我不想记住所有那些 xyz URL,我想去一个地方并能够获取我需要的一切。