SharePoint is a great product, but also a complex one. To understand it and manage it, you have to understand its hierarchy. In this article, I intend to depict and explain the SharePoint hierarchy in a way that I think will clarify some “grey areas”.
In a SharePoint infrastructure we can have one or more Web Applications. You can think of a Web Application as an IIS web site. For example, http://contoso.com can be a Web Application. http://contoso.com:6789 can be another Web Application. http://example.com can be yet another Web Application. And so on.
To a Web Application we can associate one or more Content Databases. Content Databases are SQL Server databases that SharePoint will use to store our data.
A Content Database can store one or more Site Collections. A Site Collection is a hierarchy of SharePoint sites. A Site Collection has one Top-Level Site. A Site Collection can have only its Top-Level Site, or it can be as many as levels deep as desired. We can create as many sites as we want under the Top-Level Site. Also, we can create as many sites as we want under a site we created previously. The breadth and depth of any Site Collection is up to us. But still, a Site Collection with only its Top-Level Site is still a Site Collection.
In the following diagram, I depict a SharePoint hierarchy. Please note that this diagram does not entirely cover all cases, since not only a web application can contain one or more content databases, as depicted, but the opposite is also true: A content database can contain more than one web application. Usually, though, the hierarchy is as depicted below:
Diagram 1: A SharePoint hierarchy
In the following diagram, I depict a Site Collection.
Diagram 2: A Site Collection
Each site can have lists which contain items. Also, each site can have libraries which contain documents and even folder hierarchies with documents. Don’t worry though: I will spare you and not provide another hierarchical diagram of those! But this is an opportunity for me to digress a little and provide a quick tip. When you move your folder hierarchies from your file servers to SharePoint, you do not have to keep using the same hierarchies’ structures. In SharePoint, you can flatten the hierarchies and use fewer subfolders or none at all, because you can use views instead of subfolders. In SharePoint, you do not necessarily have to use traditional filing concepts and procedures.
When you install SharePoint, you have no Web Applications, no Content Databases, no Site Collections. The simplest SharePoint infrastructure you can create has one Web Application with one Content Database and with one Site Collection with only its Top-Level Site. So you begin by first creating a Web Application. Then, under that Web Application you create a Site Collection, and that’s it: you have finished.
Now you might think that this is strange. Only two steps? You just create a Web Application and then immediately “underneath” it a Site Collection and you’re done? Well, yes. The Content Database that will hold the Site Collection is created automatically for you and, of course, by creating the Site Collection, what you effectively do is that you implicitly create its Top-Level Site.
In the following diagram (Ok, last one, I promise!), I depict the simplest SharePoint infrastructure.
Diagram 3: The simplest SharePoint infrastructure
Now, after you create a Site Collection, you can go ahead and create more Site Collections, if you want to. All Site Collections that you create will be under the same initial Content Database. But you can also create more Content Databases under the Web Application and then, when you create a Site Collection, you can specify the particular Content Database that will store it. Just keep in mind that a Site Collection cannot span Content Databases.
Depending on the SharePoint version and on the tools you use, you may be able to
• move a Content Database from one Web Application to another
• move a Site Collection from one Content Database to another (in the same Web Application or in a different one)
• move a site from one Site Collection to another (in the same Content Database or in a different Content Database, in the same Web Application or in a different one)
but such moves may not be straightforward and you should plan ahead to avoid them if possible.
A Content Database stores Site Collections and not individual sites. As I mentioned in the previous paragraph, with some work, it may be possible to move a site from a Site Collection to another Site Collection, even if the new Site Collection is in a different Content Database. It is also possible to move a site into an empty Content Database, but we have to first turn the site into the Top-Level Site of a new Site Collection that is stored in the (previously) empty Content Database. This goes to show you that in a Content Database there are only full Site Collections and not individual sites.
I wanted to include the concept of Content Databases in my depiction of the SharePoint hierarchical concepts, even though some people draw diagrams without them. Thus, SharePoint is sometimes depicted as a hierarchy of Web Applications that each contains one or more Site Collections. Although this practice is conceptually correct, it may not be comprehensive. This practice does not help one realize the place and role of Content Databases in the hierarchy. It also does not help one understand how to structure and restructure her SharePoint infrastructure. Of course, there are cases where a web application contains one or more content databases, but there are also cases where a content database contains one or more web applications. Thus, to accurately depict one’s SharePoint hierarchy, you must obtain this information, so you will know whether a particular web application will be underneath or above a corresponding content database in the hierarchy.
And, please, keep in mind that it is usually preferable and more scalable to expand a web application to many content databases than to try to contain many web applications into one content database. Thus, you should usually strive to have web applications (instead of content databases) as the top layer in your hierarchy.
The final issue I would like to address is the eternal SharePoint question: What is better for a large SharePoint infrastructure, having many small Site Collections or few large Site Collections? A Site Collection is considered small if it does not contain a lot of sites and its site hierarchy is not wide and deep. A Site Collection is considered large if it contains many sites and/or its site hierarchy is wide and deep.
The answer to this question will vary according to the particular company and its requirements. There are a lot of help in the web to find out the pros and cons about each case. The decision is ultimately up to you. But it seems to me that having many small Site Collections is the most usual choice administrators make. Also, please refer to the blog post titled “Determining Between SharePoint Site Collections and Sub-Sites” at http://blogs.msdn.com/b/sgoodyear/archive/2009/07/25/determining-between-sharepoint-site-collections-and-sub-sites.aspx
As you become more involved with SharePoint, you may find that there are exceptions, deviations and differences from the simplistic hierarchical view I presented here. And there are also more concepts than those I presented here. There are host-named site collections, farms, services, content that is not stored in Content Databases, just to name a few of the more advanced concepts. I just hope that my simplistic hierarchical presentation of SharePoint could serve you as an initial rough guide into its structure and functionality.