This post is probably not relevant to most people, but I keep running into the same discussions with companies that are setting up SharePoint for the first time or have already set it up and are asking a lot of questions about why their environment is not as flexible as they thought it was going to be. I also seem to get into discussions about this with other SharePoint integrators who don't feel that this topic is important. Maybe they assume people already know the concept or maybe they don't understand it themselves.
I feel that understanding the architecture around the definition and maybe the purpose of sites and site collections is the building blocks of SharePoint. Most people coming into SharePoint for the first time see it as if it were a single web application with a ton of features and settings. They also look at it as if the taxonomy of the sites were a physical heirarchy on a file system. Its hard for some people to grasp the understanding that everything is stored in a database and there is no real physical site hierarchy.
With the use of managed paths, site collections can impersonate a physical hierarchy for a means of organization, but the site collections are still on the same level as far as SharePoint is concerned. A Farm, Web Application, and a Site Collection are all "Containers" (or in active directory thinking "organizational units").
As far as when to use a site collection as opposed to using a sub-site, that is based on the organization itself. Usually it is the IT department’s goal to implement the SharePoint system. In most circumstances these people are infrastructure experienced and not experienced in deploying applications. This results in a hodge-podge installation of SharePoint with a single site collection to house everything known within the organization. This will result in a failed installation, since there is no room for scaling. Plus IT will either be burdened with the task of maintaining all the structure and security, or they will demand it (sometimes IT doesn't get the idea of distributed security).
Site collections will allow the IT department freedom to maintain just application itself without the worry of security or content hierarchy maintenance. The following is a list of what an individual site collection offers.
For the Users:
- Dedicated Recycle bins
- Dedicated usage Reports
- Distributed administration (site collection administrators)
- Dedicated search scopes, keywords, and best-bets
- Custom feature deployments
- Dedicated language translation maintenance
- Dedicated galleries for web parts, master pages, content types, site columns, site templates, and list templates
- Dedicated shared libraries, such as site collection images and site collection styles
- Dedicated real estate (Self Containment)
For the IT Administrators:
- Site quota templates
- Distributed administration
- Site locking
- Database maintenance options
- Backup / Restore abilities
- Content Deployments
- InfoPath forms services global template targeting
I have 2 big, at least what I think is big, points on why to use site collections. The first one is site quotas and recycle bins. The issue is the recycle bin is based on site collections and the quota for a site collection. If everyone shares a site collection, then they share the recycle bins storage size. The example I usually give is HR deletes 1MB per day and IT deletes 1GB per day. With a 5GB site quota, HR content will be flushed through the system a lot quicker if they share a recycle bin. This results in having to restore a database to get back a single document. (You know it will happen, Murphy’s Law). If they were in separate site collections, then the HR recycle bin would be valid for months maybe years with a 5GB quota because it is only affected by their deletions.
The second point is distributed administration. For most small companies this might be a moot point, but for high content driven organizations with a small IT force. It is a godsend for IT. IT doesn't know who should be able to see what content, besides how it should be organized. This is the job of the content owners and users. SharePoint site collections offers IT the ability to create a site collection for a project, team, department, document, or whatever the needs are, then assign an owner and hand it off to them. Now IT has time to work on IT related issues and the content owner now has their real estate to start developing. By this I mean, they now have the ability to quickly create libraries, calendars, meetings, wikis, whatever they feel they need to efficiently organize their content in a meaningful manner to the people who will be using it.... THEM. Plus the ability to allow users to either read or contribute to the site. This is huge since the content owners best know who needs to author, read, consume the content, plus how it needs to be organized. IT usually has no clue which then leads IT down a long time consuming road to interpret how the content owner needs it and will probably have to keep changing it constantly since they are the owner. IT has their own work to do as well.