Lately, I've run across several customers who've historically used a UNIX-based database for "really important" systems and SQL Server in other environments, and these customers are wondering how to get their companies to complete the shift to SQL Server. Over the years, SQL Server has matured and can truly compete with UNIX databases, even at the highest levels of an organization running the most sensitive, mission-critical applications. But the UNIX database folks and the SQL Server database folks are often in different departments, politicking to ensure that the next really important application is deployed in their environment.
A growing number of businesses are open to the idea of using SQL Server for the important systems that just 2 or 3 years ago would have been deployed on UNIX without a second thought. Many business executives I've chatted with lately trust that SQL Server can get the job done. But in some cases, they're concerned about bucking tradition; their teams have a long history of managing the important applications on Unix and putting smaller department-levels systems on SQL Server. These executives wonder if they can teach their old database dogs new tricks.
I'm chatting about training options with a few customers in similar situations right now, and the conversations I've had have raised an interesting question: Is it better to try to teach enterprise-class data-administration skills and disciplines to department-level SQL Server DBAs or teach deep SQL Server technology skills to an experienced UNIX DBA who has been running multi-terabyte systems with four 9s of availability for years? I've got my own thoughts about the answer to this question, but I'm not going to share them this week. Instead, I want to hear your thoughts, especially if you're in an organization that has gone through or soon will go through this type of experience as SQL Server moves up the food chain in your organization.
Send your responses to me at firstname.lastname@example.org. I'll share the most interesting reader perspectives, as well as my own thoughts, in an upcoming edition of SQL Server Magazine UPDATE.