Probably about once every three months or so I’m asked about using stored procedures to access the SharePoint databases. Sometimes the question is exactly that, just an innocent question. Sometimes it’s in effect a statement implying that our design should include queries that access the SharePoint databases directly. The view is that performace could be improved with direct access instead of going through web services or the SharePoint object model.
Every answer I have ever given has always been the same. Direct access of Microsoft’s SharePoint SQL Server databases is only supported for read operations and then if and only if the SharePoint protocols are used. Microsoft has not supported direct access of the SQL Server SharePoint databases since SharePoint 2003. I don’t recall if this was the case or not for SharePoint 2001 (well back then it would have been Exchange’s Web Storage System, not SQL Server) and I’m not going to bring up my virtual with 2001 just to take a look; it’s not that relevant.
This position strikes many as unnecessarily restrictive. Well, just walk on down to your DBA at your next opportunity and ask him or her if they mind if you write a query or two against their production application databases. Tell them you want to do this because you think you can make the apps run much faster. The apps don’t even have to be mission critical, just any old app that has the same Service Level Agreement as your SharePoint application does. I’m willing to bet large sums of money that you’ll encounter very stiff resistance if not outright refusal on their part.
Now your DBA knows you. Microsoft doesn’t know the people who could potentially be writing stored procedures or even ad-hoc queries against their SharePoint databases. If your DBA won’t let you write queries against production databases why should Microsoft support you doing the same against theirs?
Here’s another "small" complication to consider. What is one of the most important security features that SharePoint 2007 provides? (Answer: Security trimming which eliminates discovery). What might a poorly written query yield: discovery. Furthermore, locking and a number of other undesirable side-effects can result from directly accessing the SharePoint databases, even for read purposes.
For more information about this topic read this Microsoft publication (it’s been recently updated too I just noted). There you’ll also find a link to the SharePoint protocols I mentioned above. If and when you go to the protocol documentation site, look closely; SharePoint has multiple sets.
