It’s T-SQL Tuesday, the blog party that SQL Server expert Adam Machanic (blog|twitter) started. This month’s episode is hosted by Jens Vestergaard (blog | twitter). The topic: Favorite SQL Server Feature.
When I saw this topic, I was really excited. My mind started racing through all the awesome features in SQL Server. I spend a lot of time dealing with HA and DR–so many features to choose from…but are any of them my favorite? No, probably not. MSX and CMS have made my life so much easier, and they are incredibly cool, and I’ve not blogged about either of them…but…neither is my favorite.
I spent some time today thinking about some of the projects I’ve worked on in the last couple of years, and all the things I’ve implemented, and some of the things I decided not to implement. That’s when I realized that my absolute favorite feature is…
The features I don’t use
No, that’s not a passive-aggressive way of saying I hate everything about SQL Server. It’s also not a deep, existential look at the SQL Server feature set (If a SQL Server falls over in a data center, and nobody is around, does it make a sound?).
SQL Server has tons of amazing features, but it’s never a good idea to implement them all. If you implement every feature, your SQL Server infrastructure will be unmanageable. Part of deciding what the “best” feature is for a given use case is considering the big picture.
The best feature isn’t always the best solution
Sometimes, you might have an ideal, but narrow, use case for a specific feature–is it worth it implementing a feature for a narrow use case? There might be significant operational cost/effort with ongoing support for the feature. Maybe the second-best solution would be good enough. Do you need to implement CDC, or would a trigger be good enough?
Maybe your shop simply doesn’t have the technical skill to support a given feature or combination of features. Some configurations really do qualify as Expert Mode. Would you consider configuring a multi-subnet WSFC, with an AG that spans two FCIs, then take backups from the readable secondary to use for cross-domain log shipping to a third data center? That’s a perfectly valid setup, but if your team doesn’t have the expertise to support the complexity, you are probably creating more problems than you solve.
Maybe the feature just sounds really cool! Who wouldn’t want to implement “Hekaton”? Even the official name “In-Memory OLTP” sounds pretty cool. But do you really have a use case where you need it?
Restraint is cool, too
It’s really tempting to implement cool-sounding features. It’s really tempting to hyper-tune solutions to be the absolutely perfect, most-optimal solution. But it takes a real expert to realize when you’re over-engineering a solution.
Take a moment to appreciate your own restraint. Appreciate all the features that you didn’t implement because you didn’t have to. Be happy that you looked at the big picture and decided the best solution was the one you were able to support.