SharePoint administrators often learn the hard way that there is an art to creating SharePoint site collections.
In building a site collection, an administrator's choice of approach has a long-term effect on site organization and performance. While companies may take different approaches, adhering to a few basic techniques can help lay a foundation for better SharePoint usage.
Note that site collections exist to reduce the management burden by allowing sites to share a common set of features including template galleries, Web parts, permissions, content types and more. Use site collections as a tool for grouping together sites that share common elements. Conversely, site collections can serve as an isolation boundary between groups of sites that require different permission levels or even a different navigation scheme.
The most important practice is to avoid lumping all SharePoint sites into a common site collection.
Also for security reasons, internally facing sites should be isolated from externally facing sites. Microsoft recommends using separate SharePoint farms for internal and external site collections, that you have only one Web application per farm, and that you use it to contain all the site collections that will reside within the farm.
Use site collection structure to improve SharePoint performance
When developing a site collection plan, performance is a major consideration. Sites within a site collection share certain elements, such as the underlying SQL Server content database. So any site in a site collection can undermine the performance of other sites in the collection. A busy site that makes extensive use of the underlying content database can cause performance issues with other sites that rely on the same database.
Sharing a common content database has other implications as well. For one, a shared SQL database limits the number of sites that can exist within the site collection. In SharePoint 2013, the maximum number of sites that can reside in a site collection is 250,000.
For more on
Is SharePoint mobile good enough?
Six killers of SharePoint BI projects
Predictions for R2 improvements
Most organizations will never come close to creating that many sites within a single site collection. Even so, note that there is a theoretical limit. A large number of sites in a single site collection can become problematic long before the theoretical limit is reached. It is ultimately the hardware within the SharePoint server itself and the SQL Server (not to mention the network connectivity between them) that dictates the number of sites that can be created before performance and stability problems occur.
Even with high-end server hardware, creating huge site collections may not be a good idea. Large site collections can be difficult to manage. Furthermore, building large site collections can undermine disaster recovery initiatives. Remember, all the sites in a site collection share a common content database. If you ever have to restore this database, the restoration will affect every site in the collection.
Again, the most important practice is to avoid lumping all SharePoint sites into a common site collection (except in very small organizations). This defeats the purpose of site collections, which should be dictated by the shape of business processes and divided into useful groups. Ideally, the site collection structure loosely mimics -- and therefore supports -- your organization's business workflow structure, with sites that share a common purpose grouped together.