我是一家中型制造公司的 IT 经理。我们开始使用 SharePoint - 到目前为止，我们有一个博客在生产中使用> 它是 CEO 的。
我们有几个基于列表的“应用程序”的用例，其中包含一些简单的工作流程，这些工作流程将由我们的一位开发人员实施。我们还希望让我们的用户（至少是更精通技术的用户）能够创建和使用他们自己的部门网站。
然而，我们担心如果它被广泛采用，我们可能会开始一些可能很快失控的事情（这将是一件好事）。由于我们并不真正了解所有的架构权衡，我们最终可能会在一个结构中得到大量的用户数据，从而使我们陷入困境。
我们最大的问题是每次使用是否有多个站点，而不是其他所有内容都来自一个根站点。多个站点将使我们能够灵活地进行更改或开发新功能，而不会给所有用户带来问题。但是，多个站点可能更难备份、搜索和维护用户配置文件/安全性。一个庞大的网站似乎扭转了成本/收益。
我将不胜感激任何关于一个与多个权衡的见解，或讨论它的资源的链接。指向一般 SharePoint“企业最佳实践”（对不起）的链接也将不胜感激。
谢谢。
这完全取决于您的需求和要求。即使有用于不同站点的不同 Web 应用程序，我也可以为您提供一个引用，以备份为优势。您可能很少有数据不会经常更改的站点，例如组织策略、流程文档等。在这种情况下，定期备份/搜索爬网是没有意义的（尽管您可以选择差异备份和增量爬网，但仍然需要一周或两周一次）您必须进行完整备份）。因此，我建议仔细分析您的要求，然后做出决定。Microsoft 提供了一个很好的清单和模板用于规划目的。madhur 的回复中提供了一些链接，其余的你可以用谷歌搜索。
但是，多个站点可能更难备份、搜索和维护用户配置文件/安全性。一个庞大的网站似乎扭转了成本/收益。
我认为这是不正确的。首先，我们需要澄清当我们说多个站点时，我们是指多个站点集合还是多个站点——它们是两个完全不同的东西。
现在，即使它们是多个不同的站点集合，在 SQL 数据库中，它们也只是一个数据库，因为数据库是作为 Web 应用程序级别而不是站点级别创建的。
那是关于备份的。
来到搜索和用户资料，你的假设又是错误的。搜索和用户配置文件是共享服务，只要它们驻留在单个共享服务提供商中，它们就可以正常工作。两者都是农场级别的服务。
一个庞大的网站（如果你真的是指这里的网站而不是网站集）是一个完全的禁忌和糟糕的设计。
我建议您拥有多个网站集（例如贵公司的整体部门，例如 HR、财务、IT），然后在其下设置 subistes。这样，您就可以在 SQL 中管理一个数据库，并且仍然可以通过将内容数据库添加到现有 Web 应用程序来进行扩展。
再次在这里，我假设您正在公司级别创建拓扑。如果这是在某个较低的级别，则需要对其进行改进。
在继续阅读任何一篇文章之前，请阅读 Technet 上有关分类和站点架构的一些文章。
Planning worksheets for SharePoint Server 2010 http://technet.microsoft.com/en-us/library/cc262451.aspx Plan sites and site collections http://technet.microsoft.com/en-us/library/cc263267.aspx Sites and site collections overview http://technet.microsoft.com/en-us/library/cc262410.aspx Plan site navigation http://technet.microsoft.com/en-us/library/cc262951.aspx