我应该使用 SharePoint 子网站还是元数据？答案

【问题标题】：Should I be using SharePoint sub-sites or metadata?我应该使用 SharePoint 子网站还是元数据？
【发布时间】：2015-02-07 18:24:33
【问题描述】：

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

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

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

这是一个例子。

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

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

我们将不胜感激任何有关该主题的良好讨论的建议或链接。谢谢。

【问题讨论】：

标签： sharepoint

【解决方案1】：

我建议您使用元数据和视图来分隔一个存储库/站点中的数据。

我的理由如下：

在 SharePoint 中，建议使用元数据而不是“邪恶” 文件夹（或您的情况下的子网站）。请记住，维护从长远来看，多个子站点需要大量的管理工作，例如，某些站点将被继承，而其他站点将是唯一的允许。
随着时间的流逝和人的轮换，它变得模糊数据存储在哪里以及新数据应该去哪里，特别是对于大容量子站点。
由于您的案例不涉及机密性，因此保持数据集中并向相关领域的工作人员开放会增加共享和协作现象。相比之下，使用子站点会增加数据孤岛的可能性。
人们都很懒惰:)。以我为例，我不想记住所有那些 xyz URL，我想去一个地方并能够获取我需要的所有内容。

【讨论】：

不是将所有内容都放在一个子站点中，这是否意味着您需要（并依赖）人们在每次添加内容时设置所有元数据？懒惰的人可能更愿意将文件放入文档库并完成处理。
当用户将新文档拖放到具有所需元数据的 SharePoint 库中时，它不会要求提供这些列值，而是将文档签出并希望用户进行编辑该文档的属性对我来说似乎是一个交易破坏者。
这是一种文化。一家公司的人员在 SharePoint 中上传或创建新文档时可能很乐意添加属性，而另一家公司的人员则不然。从长远来看，元数据驱动更有益，而文件夹驱动则易于实现。如果我们想要使用元数据，请创建与（强制或可选）元数据相关联的自定义内容类型。在这种情况下，每次用户上传链接到这些自定义内容类型的文档时，SP 系统都会自动要求用户插入必填字段。