We all love SharePoint, but part of loving SharePoint is understanding what it can and can’t do. This is all about avoiding the “When all you have is a hammer, then everything looks like a nail” trap.

Of all the things it can’t do, the two most deadly, and therefore most commonly seen in failed SharePoint projects, are:

• High Volumes of Data – Always, always keep in mind the limits described in the should-be-memorised-by-all-SharePoint-consultants documents here:

Plan for software boundaries (Office SharePoint Server) 

Plan for software boundaries (Windows SharePoint Services)

• Relational Data – While there are some great, limited “relational like” scenarios supported by SharePoint, once you have information in one list, related in some way to information in another list, you should tread very carefully. While you may be able to fake it with small numbers of items, you can forget doing anything serious.

So, with all this said, there is one very common scenario for which SharePoint does offer some pretty nifty (though still limited) support. The scenario I’m talking about is commonly called “Master/Detail”, which is where you have a record, for example an EmployeeID, with a series of related records, for example performance reviews for each employee.

In fact it was just this scenario that Mark tackled on a recent project, and his most recent post shows how to meet it by the creative use of a new content type, based on the “Folder” type.

“Now each folder is an employee and in each employee folder you can store the e.g. performance documents.”

It’s one of those nifty little features in SharePoint that doesn’t get talked about enough. So head on over and take a look at the full solution.