Developers and database administrators frequently clash on major questions about how to scale application performance. Are they just being stubborn, or is one side really right? Jeremiah and I recently gave a talk on this topic to the AtlantaMDF User group and we wanted to open this debate to the world.
Photo courtesy of Aaron Nelson
Someone’s Right and Someone’s Wrong
Developers and DBAs are usually being stubborn, and for good reason. DBAs tend to be tasked with being the protectors of an environment, while developers are on a mission to ship more features, make changes, and bring in more money. Each side has a reason for their views, but on most controversial topics, one side actually is more right than the other.
ORMs
Most DBAs believe that Object Relational Mapping tools (ORMs) write terrible code and that stored procedures are a better data access layer. This belief is widespread because database administrators struggled for years with early versions of NHibernate and Entity Framework.
Some of the growing pains hurt: everything from type mismatches to hilariously long and tangled queries have burned people. But developers embrace ORMs for good reasons. These tools really do help build, test, and ship features more quickly. If you become a SQL Server performance tuning specialist, you can get the best of both worlds– but you have to let go of some of your hangups about ugly SQL queries.
Application Caching
It’s hard to argue against application caching… at least unless you’ve tried to implement it and come up frustrated. DBAs argue that developers should cache everything, while developers can tell you how that isn’t as easy as it sounds.
We know that usually there IS a place for caching, you just need to know how to find the “biggest bang for your buck” opportunities. (We’ve got some slides and scripts below to get you started.)
Access to Production
Who hasn’t had this argument over and over? Usually developers are fighting to get into production and DBAs are fighting to keep them out. Lots of time gets wasted on this topic needlessly.
We created tools like sp_BlitzIndex® to help people share information for performance tuning more easily. You just gotta find the right tools and the right level of access that lets everyone do their jobs (and keep their jobs).
Get the Scripts
Download ’em here.
Join Us Live
We train developers and DBAs diagnose the real bottlenecks in their SQL Servers and use data to get beyond the problems we just described. Join us at a live training event to learn how to performance tune SQL Server.
5 Comments. Leave new
Terrific, the “do regular health checks, together” part has been the key for me.
Interestingly (for me) I read a question on the same topic on StackExchange
http://dba.stackexchange.com/questions/39192/deployment-manager-vs-dba-cage-match-on-pushing-releases-to-prod/39402#39402
That’s a really interesting thread!
Oh, the perils of offloading releasing to production. I always just like to bring up the example of “So what happens when something breaks in production that worked fine *everywhere* else? Who’s on the hook and how much does it hurt?” Because something can always go wrong in just production. There’s just no way to prevent that from being a possibility. (Maybe it’s a deadlock. Maybe it’s a power failure and is actually unrelated to the change itself– it doesn’t actually matter.)
But yes, a totally controversial topic. And for the record there are some circumstances where I’m totally in favor of having devs be able to release to production. It’s all about the environment and the business requirements.