I’ve been in Adelaide for a few days reviewing a company building a product on top of SharePoint. Some of the team had been on the 4 day “boot camps” that are run here in Australia that cover developing solutions with SharePoint. One of the common things I continue to see in the “wild” is the fact that developers tend not to keep track of the information published on TechNet and MSDN. Some of this information is absolutely necessary to be aware of when developing on SharePoint, such as disposing of SPWeb for performance issues and guidance around how to architecture large scale solutions. This stuff simply doesn’t make it into most training courses and most developers attend training once and don’t go for the refresh so wouldn’t be notified anyway.
It is very common for Organisations to implement Intranets with Document Management Systems on the SharePoint platform without the knowledge that if Content Databases grow over 100Gb there are potential performance issues (as discussed in the TechNet article). Once you start hitting this limit, you really need to start splitting up the information within your solution across Content Databases, which means splitting it across Site Collections.
This is something that can be done after the roll out e.g. if you do hit the 100Gb you can start “re-parenting” sites (SPWeb) into new provisioned Site Collections (SPSite) and using managed paths to allow these to run within the same Web Application.
There are mixed opinions on the recommended 100Gb limit depending on what resources you read. This is yet another area of SharePoint that adds confusion to any implementation. As a quick test on Twitter I posted the question “Can a site collection have more than one Content Database?”, it was amazing to see the variations that I received as replies. The “death by information” on TechNet and MSDN that is spread across multiple resources around this topic doesn’t make it any easier to digest either. It’s like an IKEA instruction manual where you’re missing some bolts!
It’s not just for front end performance
Another compelling reason to split the implementation across Site Collections is because rather than having one large 100Gb database, you have multiple smaller ones.
- patching SharePoint more manageable
- backup and recovery a much faster process
- backup files more manageable
Also separating your information architecture across Site Collections allows you to delegate Site Collection Administrators across your business.