Determining Between SharePoint Site Collections and Sub-Sites

  • Article

Personally, I am in favour of a liberal use of site collections. In short, when in doubt, or unless I have a good reason for creating a sub-site, my default choice is a new site collection.

Having site collections really sets IT up with greater freedom to manage and scale the service down the road, whereas sub-sites are generally more limiting. For example, sub-sites all exist in the same site collection container and if two sub-sites grow beyond a manageable size for a single site collection, that container cannot scale out its storage without breaking the collection apart into several site collections and facing other challenges (like changing URLs or having managed path complexity, and data migration efforts).

On the other hand, if they are each individual site collections, we can easily separate them into their own physical database, and then potentially scale even further by storing those databases on different physical SQL Servers. This way, we can adjust the physical storage for site collections without affecting the logical URL structure of the site the end-user interacts with, and with minimal downtime.

Having site collections also gives you more control over monitoring the service, as we apply quotas at the site collection level. Rather than having one very large quota (or worse, no quota at all), it is better to have several small quotas on different sites that you can monitor and potentially develop reports for different types of sites, or even implement a charge-back model associated with site quotas. All signs indicate SharePoint 2010 will continue with the quota concept at the site collection level, and potentially build on some of the capabilities it offers. Quotas are a good long-term investment, not to limit end-user adoption, but to allow IT to adapt to and plan for that adoption.

I also find it easier to track and report on the site's lifecycle at the site collection level rather than individual sub-sites within it. The built in Site Usage and Confirmation feature also works at the site collection level, and I've found any workflow or customization I have developed to offer additional experiences than the built in site usage functionality offers to be the least complex when built targeting the site collection.

Finally, if I need to change an URL of a site, having a deep hierarchy of sub-sites will break links for many more locations than the site itself. If instead they are all site collections that just link to each other, I can update those links and the impact to my end-users is limited to just the one site that needs to change. If you think about it, the internet has a very flat and wide hierarchy that uses links to point to different resources, and does so in a structure that simulates a hierarchy. Your SharePoint sites can be set up with a virtual hierarchy too that uses a taxonomy structure built from links rather than a physical implementation.

It is true that sub-sites can inherit things like permissions and navigation, and this is usually the main argument to trade off a flatter site collection taxonomy for a physically deeper taxonomy based on sub-sites. Using Active Directory groups for membership and granting permissions against those groups should resolve being able to manage permissions centrally. Using separate site collections, you will have to set up the navigation on each site, or you can implement a custom navigation provider. Another challenge is that the Content Query Web Part will not work across site collections, but you could use the search results web part or build your own, and achieve the same goal of aggregating content across site collections.

Some of the key things I look at when determining whether to split content into multiple site collections rather than a single site with many sub-sites, beyond the content size and number of databases I would like to span, include:

  • If the top-level site reaches the end in its lifecycle, can I delete all the sub-sites when I delete it? If not, maybe those sub-sites should be in a different or their own site collection so they can have a different lifecycle.
  • Will the permissions for the sub-site be the same or a subset of the top-level root site? If not, this might indicate the permission hierarchy is getting overly complex with broken inheritance and would be more manageable in the future separated into different site collections.
  • Will I want to build site reports differently between sites? If I want to report on several sites as a group, it is often easier using out-of-the-box reports if the sites belong to a single site collection.
  • Will the navigation change frequently? Having multiple site collections point to each other is as easy as setting a global navigation for each site that links to each other. Nevertheless, if that global navigation changes frequently, it might be easier to have the sites as sub-sites. Or, keeping in mind that ease of updating the global navigation across site collections is achievable still by implementing a custom site map provider, site collections might work just as well.

Ultimately, it is a trade-off between easy initial site setup verses an implementation with a design for greater flexibility and manageability in the future.

The following diagram captures my typical decision process when determining the physical site structure.

 

 

This other article also discusses some of these points and has a few other questions to help you decide when to use a site collection and when to use a sub-site: https://technet.microsoft.com/en-us/library/cc288638.aspx

Remember, the virtual structure and site taxonomy (directory) can be anything, because they are just hyperlinks pointing to content. Avoid making physical structure decisions when links will do!