For years I have seen a conflict with Developers and Database Admins. I am not talking about SQL specific developers but more the application developers. And please do not get me wrong, not all developers fall into this category. Let me give you a few examples. I have had developers that were not convinced that their code should be in stored procedures. Now that is a debate all in itself, but I was allowed to bring on Kalen Delaney to help with this. The end result was that we were able to decide as a company that yes Stored Procedures where the way to go. As we started to deploy some of the new code I found that we have a couple of things happening, the biggest one was the dynamic SQL that the developers were putting into the stored procedures that was causing the SP’s to re-compile every execution. One of these made it into production due to lack of support from management and our processors took off. The end result was there were developers that were running around screaming that stored procs make it slower. This was a battle I had to wage for years at that company and I can tell you I am glad I am not there anymore.
The same company a couple of years before I left decided that they wanted to implement a SAN. I mentioned that I had heard some not so good stories about the way that this was done. So being the complainer that I am they put the SAN in my department and had us implement the SAN. Now the best news about this was that it was only after a year of this being in production before they sent my guy I assigned to it to training. This was like telling an Exchange Admin its time to learn SQL Server and oh, do it in production and without training. Kudos for the Company. (Ok that was sarcasm.)
Recently I saw a question about what San someone should pick over another and it got me to thinking. I am not a SAN guy nor will I pretend to be one. However, I am a SQL Server consultant, and I can tell you that 90% of the Sans that I have had under my databases have had major problems. Now a year ago I was willing to throw stones at the hardware, but today I find more and more it’s the way the SAN is configured. I have a hard time believing that 90% of the San’s I have been on are junk. But I know one was a learning experience, one had no administrator to speak of, and a couple of them had Window Admins that knew nothing about Databases and we treating the databases like a huge file server.
The end result is I see a growing need for people in the industry that understand how SQL Server works and how San’s work. Over the past few releases of SQL Server we have seen some real expanding of the product, and I am glad to see that SQL Server is really taking all this on. We now have needs for:
- Database Administrators
- Database Developers
- Database Architects
- Business Intelligence Specialists
I believe a good architect would understand the inside the database and the hardware architect side of the house. There are things that they should know, for example, database mirroring and the differences between that and replication, how to get the logical data split into a physical structure that will remain quick and easy to retrieve data. When a table should be partitioned and when it should not be.