Over the years, I have dealt with a lot of third-party applications (and their vendors) that use SQL Server as their back-end databases. It has often been an uneasy relationship, fraught with pain and tribulation. The overriding feeling I have gotten from most of these vendors is that they could care less about the DBAs who have to install and manage their application’s databases.

Whatever excuse third-party vendors have for ignoring the DBAs who tend to their product’s databases, I think it is time that DBAs begin to fight back, and not take their uncaring attitude any more. Below, I have proposed a DBA Manifesto, a list of demands that we need enforce among all the third-party vendors we work with. If we stick together, and take the same stance, then perhaps we can get these vendors to be more helpful and cooperative.

Here are our demands to these third-party vendors:

• Given the thousands, tens-of-thousands, or hundreds-of-thousands of dollars we spend on your product, please document how it works. Don’t force us to take the time to figure it out for ourselves through trial and error (we are already too busy), or to call tech support to get answer that could have easily been included in the documentation.
• When we call tech support, have somebody available who not only thoroughly knows your application, but understands how it interacts with SQL Server. When I call up, complaining about a query executed by your application that is missing a WHERE clause and is returning over a million rows to a list box on a user’s screen, I expect that person to understand what I am talking about.
• Don’t charge us $1,000+ a day, plus expenses, to install your software, when all we really need is decent documentation.
• If you do force a consultant down our throat (as part of the total “sales package” for your application), have the decency to send one who knows your product, and SQL Server. More often than not, the expensive consultants who have shown up at my door barely understand how their product works, let along know anything about SQL Server. I have seen many consultants spend their entire onsite time on the phone, having someone step them through the installation process of their own application. Hey, if that’s all it takes, I can talk to the same person and my company doesn’t need to waste money on consulting fees.
• Don’t tell us that only “your consultant” has the ability to configure SQL Server for your application on our hardware. Your consultant is not touching my SQL Server. They can instruct, and watch, but not touch. My former manager actually threw a consultant out from the building once because he demanded to be the one who performed the SQL Server configuration side of the installation.
• Have a real SQL Server DBA on your staff who can guide your developers so they write properly optimized code, and so that if we have a question, we can speak to someone who really understands SQL Server.
• Help us size the hardware needed to run your software. Give us some guidelines so we don’t end up under-sizing or over-sizing the hardware we buy to run your application.
• Please ensure you have tested your software so that it meets our load requirements. On more than one occasion, I have found out that we were the vendor’s largest customer, and that they had never load tested their software for a company of our size.
• Don’t blame SQL Server or Microsoft for slow running code. You are the company who has written the application.
• Don’t tell us that your application requires SA access to run.
• Use a properly normalized database design, write optimized queries, and include appropriate indexes.
• Write your code so that it is optimized for SQL Server, not written generically so that it can also run with other databases. This almost always hurts performance.
• Don’t ever tell me I can’t add indexes or security to your database. I have had vendors tell me that if I make any change in their database, that it will void our support contract. Those are fighting words to me. The only reason I have to do this is because you don’t know what you are doing, and I have to fix your mistakes.
• When it’s time to upgrade, provide a clear migration path, and perform the database migration automatically. Don’t expect me to manually port the data from your old schema to your new schema.

Do you agree with these demands? Do you have other demands? Will you try to enforce these upon your vendors? Tell me what you think. DBAs, we must unite against the tyranny of third-party vendors!

Share this post :