Kevin Hill talks about a bugbear of mine:
As a SQL DBA, what do you do when a vendor application has performance problems that are code related?
Server settings don’t generally seem to be an issue.
Queries and vendor code…total hands off. I just point at code and say “There’s a great choice for optimizing in your next update!”
Indexes are the “Sticky Bits” in between client data and vendor code.
To an extent, I do feel for software vendors, who have to write software that works in a variety of environments with a variety of workloads. That can be a real challenge, especially because the people developing those databases don’t get to monitor them in real time and observe what’s going on until someone reports an issue.
That’s the empathy part. The other side of the coin is, there are a bunch of vendors who have garbage-tier database designs and awful queries. And as a user of this third-party application or a consultant trying to help users of the application, that can be frustrating. The reason is, like Kevin mentions, you really don’t want to go mucking with the queries or database design, because with my luck, the change I make to improve a query’s performance will affect a trigger nested three levels deep in some totally unrelated process that somehow manages the data integrity of the entire application.