At one point, test database deployments within my department were handled directly by the database developers. The typical process was that the developer would unit test their changes in the development environment, then:

1) Migrate their changes to the test environment.

2) Send an email to the testers to let them know the changes were available in the test environment.

This was a solid process, which typically took only a few minutes to complete, and was nearly always completed successfully.

However, at one point the head DBA for my company took away all database owner permissions from the database developers on the test environment so that test database deployments are now handled only by DBAs. Over time the process morphed into the following:

1) Database developers complete a 15 page form to list the changes they need to migrate (for a typical deployment, most sections are blank, but the applicable sections are scattered throughout the form)

2) The database developer completes a 1 page script header for any migration scripts involved in the plan

3) The database developer references a deployment project containing all of the objects to be deployed in the plan

4) The database developer sends an email to the department head requesting the deployment

5) The department head approves the plan, scripts and project

6) The department head forwards the email to the primary DBA for the database

7) The DBA either approves the migration, or rejects it (typical rejections are due to a section of the 15 page form or 1 page script template not being filled in, or the 15 page form not being the most recent version of that form)

8) The developer completes a 2 page form email to the testers, letting them know the changes that are scheduled to be migrated

9) The DBA sends an email to the developer and department head letting them know the deployment was complete. Or alternatively, that it could not be completed.

10) The developer replies to the 2 page form email, letting the testers know the deployment was completed.

So, a process that once involved a single person, took less than five minutes to complete and had a near-zero failure rate now involves a minimum of three people and takes a minimum of twenty minutes to complete. In addition, deployments submitted after 2:00 PM often cross over into the next day based on DBA and department head availability.

Along similar lines, the head DBA has published a 50 page standards document. The majority of the document is focused on what he feels things should be named, the use of acronyms, underscores, capitalization and so forth. However, it also includes some time-consuming non-functional requirements. For example, adding database descriptions to all parameters for all objects. Or requiring all constants used in the database to be drawn from a numerically keyed constants table. Which means that execution plans can't be optimized based on the values for the constants. The 50 page standards document also includes a number of prefix/suffix naming conventions that are now considered industry anti-patterns.

The head DBA often refuses to deploy anything that does not conform to the latest version of this document, which changes on average every two months and often reverses previous positions. Ostensibly this is to 'raise the standards used in the department' but in reality quality has fallen off considerably since he implemented these policies. The time that used to be spent improving the existing code base and adding new features has been diverted to renaming database objects and regression testing the changes. The database developers in the department estimate they now spend 40% off their time dealing with standards and processes put into place by the head DBA. All of which have a negative or no impact on the performance and stability of the applications supported by the databases.

Has anyone out there had luck dealing with inefficient DBAs? Or alternatively, have any similar stories they'd like to share?

  • Did you have naming conventions before? What happened when a migration was deployed in the environment but had bugs? I'm not saying that your new process is better in all aspects but perhaps the change has been for some reasons. Commented May 24, 2015 at 0:32
  • The naming conventions that were followed before were internally consistent within each database. Most databases followed a ProductID convention, some followed a product_id convention, and a few followed conventions outside of both of those like ProductIdnt. The new naming conventions don't follow any of the previous ones. As for deployments with defects, if a change was rejected by QA the developer would correct the problem in development and then deploy the updated code to the test environment. The process is the same now, just with considerably more lag time between deployments.
    – Anonymous
    Commented May 24, 2015 at 1:59

1 Answer 1


The DBA StackExchange was made to address technical and strategic aspects of DBMS products and deployment of such into infrastructures. When it comes to dealing with difficult DBAs, there is no black-and-white answer to offer. In your particular case, I will make an exception.

I answered two interesting posts four(4) years ago

I discussed 4 ways people have become DBAs. Somewhere, over the course of time, your head DBA has lost touch with what Developers and Developer/DBAs are doing and their ever-changing needs. In fact, times have changed and the developer technologies of today may no longer be in the head DBA's wheelhouse.

You need to comply with the standards put in place until productivity slows down considerably. OH, I AM SORRY, THAT'S WHATS HAPPENING NOW !!!

Guess what? You must get a third-party involved (his boss or his boss's boss) and thoroughly prove that the standards are interfering with product development. In other words, your Agile Development has become Fragile Development.

I recently saw a picture in LinkedIn that might reflect what you are going through


Have all your ducks in a row. Do all you homework. Have all your facts and figures down in writing. Think of it in terms of Six Sigma: You want to streamline process development while eliminating wasted efforts.


Mind you, you should never approach this with a complaining spirit. You need to present this situation in such a way that the you want the head DBA on your side instead of off your back. If the head DBA is in your company, he/she brings something to the table in the eyes of your company. You don't want to diminish the head DBA's dignity. You must find a way to appeal to it. Notwithstanding, you must also let the current productivity speak for you and the head DBA (without casting blame). In the end, you will find the solution that creates a team atmosphere which includes the head DBA or the company may step in with standards even harder to deal with. Now, GO DO YOUR HOMEWORK ...

Please let us know how it turns out !!!

  • Thanks, this is a helpful post, and your original post generated some good discussion as well. I think most of my frustration dealing with this DBA stems from his inability to separate functional database standards, like specifying every table must have a primary key, from non-functional standards, like specifying every primary key must have a name beginning with PK. He also conflates process with quality, and is as anti-Agile as anyone I've ever met (favors processes, tools, comprehensive documentation and extensive planning over working software and responding to change)
    – Anonymous
    Commented May 24, 2015 at 2:52

Not the answer you're looking for? Browse other questions tagged or ask your own question.