我想知道大型 Sharepoint 2007 架构的通用准则是什么？大多数情况下，我想计划需要多少个网站集，以及为什么我应该将我的 Intranet 拆分为多个网站集，而不是只用一个来统治它们？
由此衍生的问题是不同网站集的缺点是什么。据我所见，他们无法相互交谈（即 CQWP 无法从另一个网站集中读取数据），我必须在每个网站集中部署我的功能。
有没有关于更大规模 Sharepoint 架构的好的资源和白皮书？我找到了一些告诉我有多少服务器的东西，但我正在寻找更高级别的东西，谈论应用程序池、内容数据库和站点集合。
这取决于您计划实现的目标。
如果您将拥有一个用户数量较少的小型农场，那么您不必考虑这一点。但是，当您部署一个非常大的场时，您应该注意软件边界。
正如您在 Technet 文章软件边界计划中所见，如果不考虑某些因素，SharePoint 会以指数方式降低性能。
我建议您注意这些性能问题，而不是网站集。网站集有其优点和缺点，但是当您使用大型场 (100GB+) 时，Microsoft 建议对内容数据库使用单个网站集和配额。希望这可以帮助。
-马克西莫
除其他外，网站集提供了管理和安全边界。默认情况下，网站集 A 的网站集管理员对网站集 B 没有任何权限。您可以单独指定这些管理员。此外，SharePoint 组存在于网站集级别。因此，您创建的每个 SharePoint 组都可用于网站集中的所有网站。
对于我们的 IT 小组管理的主要 Intranet，我们发现一个网站集运行良好。IT 控制安全并委托对内容的控制。但是，对于部门或分支机构级别的门户，我们发现创建具有配额的网站集允许我们为用户提供协作门户，而无需过多的 IT 时间投资或担心他们会搞砸上另一组的数据。这样做的不利之处在于，用户要么必须接受培训，要么只是深入研究并被告知要弄清楚。
我们已经看到，分离网站集管理的另一面是，有时拥有一个管理点会更方便。但是，我们已经能够使用一些 PowerShell 命令和脚本来解决这个问题。Gary LaPointe 的stsadm 扩展和 PowerShell cmdlet 非常有用。
我是 SharePoint 管理新手，我的组织也是如此。我们现在正在为这个问题而苦苦挣扎，所以对这个答案持保留态度。
将所有内容保存在单个网站集中的主要问题是您不能跨多个数据库破坏该集合。一旦单个内容数据库变得太大，您将开始看到性能问题，更不用说备份和恢复大型数据库所带来的所有麻烦了。
各种资源会告诉您不同的故事，说明在这成为问题之前您可以将特定数据库增长到多大，但我听到的最大指导方针是 100GB。这是 SharePoint 专家 Joel Oleson 的建议。因此，作为一项规则，如果您认为您的内容有朝一日可能会增长到 100GB 以上，请立即拆分为单独的网站集。事后将内容移动到新的网站集是非常痛苦的。
Joel Oleson 的这个幻灯片达到了容量规划和农场架构的最高点。
我刚刚看到 TechNet 有一本更新的书可供下载。
大小对于性能很重要，但不要忘记备份和恢复损坏的网站集需要多长时间。