A week ago I received from Microsoft notification of a web seminar on Managing SharePoint Databases in SQL Server. Nothing outstanding about that, they do lots of these things every day. What did get my attention, however, was description of the webinar.
“Today’s SharePoint administrators must also be part-time DBA’s in order to optimize SharePoint performance in the enterprise. But ruling your SharePoint databases via SQL Server management tools can be a pitfall of disastrous outcomes due to unique database schemas and the syntax employed by SharePoint services in accessing the databases.
Don’t let your good DBA intentions damage your SharePoint environment’s stability and performance. Join this session to learn best practices and procedures you should avoid when manipulating SharePoint databases directly via SQL Server management utilities. Demonstrations of techniques are captured in real-time from a live environment to illustrate good and bad practices for managing SharePoint databases in SQL Server.”
Over the last five years, Microsoft has been moving everything to sit on top of SQL Server. Active Directory and Exchange are due to move to sit on SQL Server according to Microsoft briefings while SharePoint and other applications such as Visual Studio are already using SQL Server as their repository application. This is a good thing. After all, databases are ideal for managing and indexing large amounts of data.
With Visual Studio, we have seen the benefits of this approach. The introduction of Team Foundation Server meant that the whole development cycle from architect to developer, tester to DBA could all store their data in the Team Foundation Server repository and all that changed was the way that they viewed their data. This is role based access working well.
When it comes to applications, however, Microsoft is much less organised. The SQL Server Management Studio might seem like the obvious place to manage all instances of SQL Server. Not so. As the above webinar description makes clear – you need to use application tools to manage SQL Server because the applications use “unique schemas”.
Hmm, I thought the the whole point of a management suite focused on a product should be to manage all instances of that product. For example, I don’t Visual Studio for Windows SmartPhone or Visual Studio for Web Design or Visual Studio for C# in order to write apps for those languages or platforms. Instead, I open Visual Studio and start a new project telling it what I am targeting and it then sets up my libraries.
It should, therefore, be equally simple to have tabs inside SQL Server Management Studio marked AD, Exchange, SharePoint, etc. Each of these should be able to import the correct schemas and understand the idiosyncrasies of the application servers.
Such an approach would allow me to have proper DBAs who understand what is involved in managing databases, how to distribute the corporate databases over our network and, more importantly, as business transition to the Cloud, how to ensure that the databases are fit for purpose when working with these applications.
Unfortunately, Microsoft doesn’t see it that way at all. To avoid a lot of anti-competitive lawsuits, Microsoft has constantly maintained that all of its divisions operate separately and that there is no sharing of Intellectual Property (IP) that wouldn’t be shared with a partner or competitor.
The fact is that these people do interact. It might not be a formal passing of each piece of technology through an approved process but they eat in the same canteen, play on sports teams, go to each others houses, you get my drift.
It would be easy to call this a big conspiracy to sell more training, consultancy and product. Sadly, this is more than the left hand not talking to the right hand, it’s about being dysfunctional when it comes to grown up management of products.
From years of dealing with Microsoft they normally counter any such accusation by saying that the leave this to their partners and for companies such as Quest, this is fantastic. Every incomplete Microsoft product is another opportunity to write a tool and make money. But it shouldn’t be down to partners to fix something that is clear wrong.
As soon as I received the above Webinar invite, I emailed the Microsoft UK Press Team asking to speak to the SQL Server team to find out why SharePoint administration was not a part of SQL Server administration. I also wanted to know if they would tell me where SQL Server Management Studio was going to go in terms of supporting applications built on SQL Server. So far, and not unexpectedly, there has been no response.
Microsoft SQL Server is a very good database, I use it for a lot of stuff, but things like this make me question Microsoft’s understanding of what real management is inside other people’s enterprises and their commitment to provide the DBA with a comprehensive tools environment.
———-Colin Rippey | August 24, 2010 1:34 PM
AD and Exchange do not use SQL Server for storage, where do you get your information from?
———-Ian Murphy replied to comment from Colin Rippey | August 24, 2010 3:01 PM
Colin, thanks for that catch. My mistake as this was still a draft and I set it live in error. Have now corrected it to read as it should have done and fixed a couple of spelling mistakes as well.
Microsoft has been talking about this for years as part of getting rid of the Jet engine. They have made it perfectly clear that they see the need for a single database with SQL being the preferred candidate but the internal politics make it a serious problem for them. One of the early discussions I had with people on the Windows 7 team was that they wanted to move their registry to be a SQL object but with time and other issues, that was dropped.
Maybe, one day, they will finally deliver on all those product plans