我想知道大规模Sharepoint 2007架构的通用指南是什么？ 大多数情况下，我想要计划需要多less个网站集，以及为什么我应该将我的内部网分成多个网站集，而不是只有一个来统一它们呢？
由此产生的问题是不同网站集合的缺点。 从我所看到的，他们不能相互交谈（即CQWP不能读取其他网站集的数据），我必须在每个网站集上部署我的function。
大型Sharepoint架构上是否有很好的资源和白皮书？ 我发现了一些告诉我有多less服务器的东西，但是我正在寻找更高层次的东西，谈论应用程序池，内容数据库和网站集。
这取决于你打算实现什么。
如果你打算build立一个拥有less量用户的小农场，那么这是你不必考虑的问题。 但是，当您部署一个非常大的农场时，您应该注意软件边界。
正如您在本“Technet 软件边界文章计划”中所看到的，当某些事情未被考虑时，SharePoint会以指数级的方式降低性能。
我build议你注意这些性能问题，而不是网站集。 网站集有他们的专业版和服务器，但是当您使用大型农场（100GB +）时，Microsoftbuild议使用单个网站集和内容数据库的配额。 希望这可以帮助。
-Máximo
除此之外，网站集还提供pipe理和安全边界。 网站集A的网站集pipe理员在网站集B上默认没有任何权限。您可以单独指定这些pipe理员。 另外，SharePoint组存在于网站集级别。 因此，您创build的每个SharePoint组都可用于网站集中的所有网站。
对于我们的IT小组pipe理的主要内部网，我们发现一个网站集合工作得很好。 IT控制安全并委托内容的控制。 但是，对于部门级或分支机构门户网站，我们发现创build具有配额的网站集可以使我们为用户提供协作门户网站，而不需要太多的IT时间投入，也不必担心他们会陷入混乱另一组的数据。 这样做的不利之处在于，用户必须接受培训，或者只是深入研究，并告诉他们弄明白。
分离我们所看到的网站集pipe理的另一面是，有时候一个pipe理点会更方便。 但是，我们已经能够通过一些PowerShell命令和脚本来解决这个问题。 Gary LaPointe的 stsadm扩展和PowerShell cmdlet非常有用。
我是SharePointpipe理新手，我的组织也是如此。 我们现在正在为这个问题而苦苦挣扎，所以拿一点盐来回答这个问题。
将所有内容保存在单个网站集中的主要担忧是您无法将集合分散到多个数据库中。 一旦单个内容数据库变得太大，您就会开始发现性能问题，更不用说备份和恢复大型数据库时遇到的所有麻烦。
各种资源将告诉你不同的故事，在这个问题成为问题之前，你可以发展一个特定的数据库有多大，但是我听说的最大指南是100GB。 这是SharePoint大师Joel Oleson的build议。 所以一般来说，如果你认为你的内容有一天会增长到100GB以上，那么现在可以分解成单独的网站。 事实之后，将内容移动到新的网站集中是非常痛苦的。
Joel Oleson的这张幻灯片打破了容量规划和农场build筑的高点。
我刚看到TechNet有一本更新的书籍可供下载 。
大小对于性能很重要，但不要忘记备份和恢复损坏的网站集需要多长时间。