Last week's "Paradox of Simplicity" commentary provoked many passionate responses. I'm revisiting the topic this week for two reasons. First, several readers highlighted interesting side effects of the paradox that I hadn't considered. Second, I forgot to mention Microsoft's part in creating and perpetuating the problem.
The following reader comment nicely summarizes the theory I introduced last week: "You hit the nail on the head! I can't count the times I've had to fight the notion that SQL Server is 'junk' compared with the over-priced databases that run on UNIX. In every single case, it's exactly as you said. Experienced DBAs (who make big bucks) install and administer the UNIX database while the manager's brother, who 'has done a lot of work with Microsoft Access,' installs SQL Server. The inevitable problems are blamed on SQL Server rather than on the people who created the situation."
In other words, many SQL Server failures occur because the product is so easy to use that anyone can get it running; SQL Server doesn't present the UNIX platform's setup and configuration barriers, so it doesn't get the same amount of resources.
Here are some of the interesting side effects readers pointed out.
Microsoft is losing revenue:
"I recently participated in a proposal and benchmarking effort for a well-known dot-com that had problems with a SQL Server application written by inexperienced internal staff. I spent several days showing the company how poorly its staff had set up SQL Server and the related application and what could be done to remedy the situation. Instead of following my suggestions, the company decided to spend several million dollars to pilot an Oracle solution because of fears that SQL Server 'couldn't cut it.' The company shelled out a large chunk of change for a new UNIX box, Oracle software, and professional services, then hired experienced Oracle DBAs. Of course the new system was much faster, and the company declared it had been right all along."
Are you smarter than the database?
"We need to educate database professionals, but that's easier said than done. In SQL Server's case, the best practical answer is for Microsoft to continue making self-tuning and wizard improvements that are smarter than the average DBA. I think that's the biggest competitive edge SQL Server has over Oracle and DB2. Microsoft seems genuinely interested in making its DBMS self-configuring and self-tuning. Someday, more organizations will wake up to the huge costs (perhaps mostly hidden) of employing a herd of highly paid Oracle and UNIX gurus to perform what should be the most basic of configuration and tuning tasks."
History repeats itself:
"We faced similar issues on the mainframe 20 years ago with the advent of 'fourth-generation languages.' They were a wonderful productivity improvement, but novices who had no understanding of the underlying database wrote some remarkably slow resource hogs."
Show me the money:
"A year ago, many of my friends and colleagues jumped into Oracle DBA positions and are now earning more than $100,000. I have the same level of experience, but I earn considerably less money simply because I work with SQL Server instead of Oracle."
SQL Server salaries are on the rise, but this reader is right. For the most part, equally experienced Oracle DBAs tend to earn higher salaries than their SQL Server counterparts, in large part because UNIX OSs and DBMSs are more expensive and companies can justify the higher salaries.
Now I'm going to get on my soapbox and tackle Microsoft for helping create this problem. Yes, Microsoft produces a fabulously easy-to-use database, but the company also perpetuates the fallacy that SQL Server is so easy to use that it doesn't require experienced and properly compensated DBAs. Microsoft sells ease of use and hesitates to point out that a SQL Server environment is often just as complex—and expensive—to manage as its UNIX counterparts. Too often, Microsoft doesn't give its customers realistic expectations about the time and level of effort required to properly support SQL Server. Customer satisfaction is an exercise in managing expectations. If customers perceive that SQL Server requires little or no full-time support, then find out differently, they'll be disappointed and future revenue will suffer. If customers understand the proper level of effort and skill SQL Server management requires, they'll be thrilled with SQL Server's ease of use and future SQL Server revenues will benefit.