When to use a Site Collection over a Sub-Site

When should you use site collections over sub-sites in your design?

Site collections really bring a considerable amount of flexibility and scalability to your design and I would recommend that you start from the perspective of multiple site collections and then see if you can find logical and compelling reasons to move away from them.

Here are some general guidelines that you should consider before you create a site collection or a sub site.

Consider the core purpose of the site structure you are contemplating. Consider it in relation to the other site structures your portal may house. It is generally not advisable to intermingle disparate sites in the same site collection. For instance you probably would not want your Internet presence site and your collaboration portal to all be part on the same site collection. There are simply too many moving parts that are completely unrelated to one another to make this feasible. While this is a simple example you could consider something such as separating out department sites or even project sites. I do this a lot simply because HR may need a different approach to security than Finance.

If distributed control is something that you want then multiple site collections would be the best way to go. Site collections really are the first layer where we can truly separate out security and administration. Although we can break security inheritance at the site level these still fall under a single umbrella or controlling entity, the site collection and its administrator. I see this a lot when it comes to those core department sites that any organization has. Many times Human Resources, Finance, IT, and Operations will be separated out into their own site collections to provide an additional layer of content control.

Boundaries are a consideration as well. Some of the key components that make up a SharePoint site are scoped to the site collection level. While there are ways around these boundaries they should be accounted for in your design. The following is a list details some of these components.

• Site Columns and Content Types
• Site Quotas
• SharePoint Security Groups
• Recycle Bin
• Site and List Templates and Master Pages
• Search Scope and Keywords
• Out-of-box Back up and Restore capabilities
• Separate Content Databases

If you have groups that cannot share resources they really need to be broken out into separate site collections. Governance can come into play here from the stand point that if the two groups should not have the ability to view or control one another's content then they should be separate or a single, and separate, entity should administer the site collection.

Finally one of the biggest drivers for a separate site collection is security. The ability to place an entirely separate security structure around each site collection can be critical. Site collections can also be broken out into separate content databases which can offer an additional layer of security at the database.

My general feel on this is to begin my design with multiple site collections in mind and then see if I can find a valid reason to deviate from that design. Sometimes the reason is there but more often than not I find that site collections simply bring too much to the table.

Site Settings at Top Level Site or Site Collection:

http://sharepoint.domain.com/sites/IT

Site Settings at Sub Site:

http://sharepoint.domain.com/sites/IT/SoftwareDevelopment
Or
http://sharepoint.domain.com/sites/IT/Testing

Note: I have copied this post from Joe Shepherd's blog. Thank you very much Joe for such a great post!