Written By: Matan Yungman 11/08/2014
If you’re reading this, you probably think, like me, that SQL Server is an awesome product. One of the great things about SQL Server is the fact that it’s super easy to start working with it: You download the installation (or connect to the Azure portal and get a VM), and after a few clicks you can create tables, load data and write Select statements.
But this is also a drawback.
Here’s a scenario:
I saw this scenario happening a few times in the past few years, and the main reason for that is frustration. People are frustrated when their processes are slow, when it’s hard to develop new features, when they don’t get help and when they don’t see an improvement in the horizon. So they start looking for other options, and there are many of them today.
Once this decision is made, it’s pretty much impossible to change it. One of the reasons for that, except for ego, is that the migration is a considerable investment, and the managers won’t want to throw this investment to the trash. In addition, a lot of times (but not always), the migration will be done after carefully learning the new platform and applying best practices, which will make the new platform work well, at least at the beginning. This is because the company is more stable now, and budgets can be invested in the migration.
The possibility to change this sometimes comes after the managers realize the weaknesses of the new chosen platform, but that can take a while.
And that’s why you should be a proactive DBA!
It’s your job to make sure your company leverages SQL Server’s full potential before it starts looking at adventures with other database platforms. By being proactive and spotting problems when they are small and before frustration starts to spread across the organization, you can save your organization a lot of time and money, keep SQL Server as the main database platform of the organization, and save you the hassle of learning how to work with a new database platform, or worse, finding a new job.
* To be balanced, SQL Server doesn’t fit every scenario. There are shops that use more than one database technology side-by-side, for example – crunching things in Hadoop and then spilling the output to SQL Server. Your job here is to know what data and processes fit SQL Server and what should be put in the other platform.
Here’s 10 things you can do for a start:
If you show your managers that things are under control, it will be harder for them to declare that “SQL Server doesn’t scale” and go on a hunt for a new platform.