Database Administrators Stack Exchange is a question and answer site for database professionals who wish to improve their database skills and learn from others in the community. It's 100% free, no registration required.

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

The answers and comments on the version and version of the question "What are the arguments against or for putting application logic in the database layer?" are very revealing about the divide between DBAs and programmers in some workplaces.

What could DBAs do differently to work better with programmers on issues like this?

Should we:

  • Study the tools and languages our programmers are using to understand their difficulties they face, particularly when working with well designed databases?
  • Encourage programmers to be better educated about databases and the advantages of having business logic at the database level?
  • Change the way we define interfaces to our data - such as by using more programmer friendly transactional APIs (eg for issues such as backwards compatibility)?
share|improve this question
Thank you for not misusing the apostrophe in DBAs (i.e. DBA's). – Nick Chammas Aug 11 '11 at 16:58
I think those two threads should be required reading for both application devlopers and database people. – HLGEM Feb 14 '13 at 20:05
Of course the opposite question should be asked as well, How can programmers be more dba friendly. – HLGEM Feb 14 '13 at 20:06

12 Answers 12

up vote 27 down vote accepted

From a Programmer standpoint, I would say the thing we want most is consistent, well defined and implemented standards for how the data layer will be designed and built. I am willing to play the way you want in your sandbox, you just need to tell me what you want, and not change the rules all the time. It should be implemented the same for everyone, even superprogrammergod. If you make exceptions for him then you want me to support and change it but re-implement it the right way that doesn't work for me.

And please do not tell me not to do it that way and walk away. Work with me to show me what you want, and why your way is better. If I understand I will comply every time. When I don't get it then its harder to comply. I do not want to be a DBA. I love programming I do not want your job and if you are a good DBA then I will be your biggest fan.

share|improve this answer
You sound like a developer with childlike humility. A DBA should also try have this same childlike humility. This is what keeps children in the same sandbox. +1 !!! – RolandoMySQLDBA Jun 7 '11 at 18:21
+1 for "Work with me". DBAs and DBIs and AppIs are all simply members of the same team, with the team goal of making some businessperson's job easier. – Greenstone Walker Sep 24 '13 at 20:56

I've been a MySQL DBA for the past 6.5 years. I've also spent some 16 years as a developer and have interacted with many DBAs. Many of them pragmatic. Some of them obnoxious. A few have no idea what it means to be a DBA.

I have come to this conclusion:

Technically speaking, DBAs who have one or more of the following qualities are the best to work with:

  1. Spent years as developers themselves
  2. Have a grasp of database theory
  3. Have a good understanding of how the RDBMS works internally
  4. Have superior knowledge of the operating system

Very disciplined, knowledgeable DBAs have a lot to share and offer. They may see database performance from a perspective not really considered by Developers. Developers know what they want from the database. DBAs know how to be "polite" to the database.

As far as personalities go, there will always be conflicts, pettiness, and maybe even envy. One thing is for certain: In no particular order, DBAs and Developers are like husbands and wives (I've been happily married for 16 years with on-going projects [4 children]).

Regardless who is viewed as the husband and who is viewed as the wife, these principles apply:

  1. one must consult the other
  2. one must value the perspective of the other
  3. one must make decisions for the good of both parties
  4. one must support, and not sabatoge, the decision made
  5. one must not denigrade the other if decisions result in bad consequences
  6. one must rejoice in the contribution of both parties to the success of decisions
  7. one must consult a higher authority (HA) if a decision cannot be mutually agreed upon

These seven(7) principles apply just as much in the workplace, especially in the IT realm.

By communicating every step of way, all should :

  1. layout their expectations
  2. engender respect for the other party's ability to do their part based on past performance
  3. have trust and confidence that the other party can complete their assignment
  4. live up to our own expectations
  5. acquiese under the guidance of the HA (see principle #7)

There is no room for micromanagement in this. DBAs SHOULD NOT TELL Developers how to think like DBAs. Developers SHOULD NOT TELL DBAs how to be Developers. Final decisions on database performance and usage must rest with DBAs. Final decisions on application needs must rest with Developers. This symbiosis must be maintained always.


Principle #7 requires active participation and oversight by the HIGHER AUTHORITY (the HA), i.e., project manager, team leader, lead developer. Your HA better know how both parties work individually and how both parties should work together. If the HA does not establish ground rules for both parties, or if the HA fails to guide the parties individually and together, projects will always come to a halt at some point and endanger the very existence (employment) of the Developer, the DBA, or even the HA.

share|improve this answer
+1 Another very thorough and considered response – gbn May 2 '11 at 18:03
Thanks for the thoughtful answer Rolando - If I may disagree to some degree, I think a better use of the husband and wife analogy would be that the DBA should use his superior authority to serve the developers rather than serving his own ego or fiefdom as is sadly sometimes true (I know I've done it) – Jack Douglas May 3 '11 at 9:49
@JackPDouglas ROFL !!!! I was just being fair to both DBA and Developer camps. In some respects, your point is very valid when the HA is proj manager. It goes the other way when the HA is lead developer. DBAs should not built a moat and a big castle wall and leave it at that. DBAs should be more like Camelot where all is welcome. – RolandoMySQLDBA May 3 '11 at 14:47
+1: awesome analogy, thoughts, and perspectives. I am a developer who once wanted to be a DBA. A good DBA realizes when they don't have what it takes and does something else! But there is something about 1's and 0's that get under your skin and won't leave you alone ... – IAbstract Jun 1 '11 at 23:03
@IAbstract Thank you. Sometimes if you let your employer waste your talent, you should move on. Check out this perspective about transitioning to a DBA :… – RolandoMySQLDBA Jun 1 '11 at 23:12

Having teams sit in different sections/floors somehow seems to encourage "us vs them" mentality.

Sitting a DBA right in the middle of the development team is a great way to tear down the programmer/DBA wall. Both the DBA and the programmers will benefit from this, if they remain open minded and put their egos aside.

Face to face communication, especially when sharing ideas, is far more effective than email and has less chance of causing hard feelings due to misunderstandings.

share|improve this answer
You can't do subtle or humour in email either. F2F is always best. If you can't co-locate (eg big shop) then are DBAs invited to planning or daily standups as mitigation? – gbn May 2 '11 at 13:54
I have recently been invited to daily standups for several teams. It is a great way to put a face to a name. People get to hear about what I have been up to (i.e. supporting them behind the scenes) and I also get to hear about their trials and YES please keep inviting us to the dailies. – datagod May 2 '11 at 14:28
Excellent point. Having never worked in a separated environment I can only imagine the difficulties this would present. – Leigh Riffel May 2 '11 at 14:30
In our shop I've been close to all of our teams (dev, QA, support). What I've found is that the communication is the only key and it has to be both ways. Without having the right mindset you can't show developers what you need and and can't see what they need. Both sides need a bit of understanding of each other's side. It would be useful for a developer to understand how that big rock on the diagram keeps data and how to retrieve it properly. It would also be useful for a DBA to understand the business logic, so they can provide better data structures. – Marian May 2 '11 at 16:21
I was in a contract where the DBA was sitting in the same area of the developers. It was an incredible experience. So far this was the only time I saw this. I try to be very friendly to the DBAs where ever I work. I've learned a lot from them. I wish more shops would put both DBAs and Programmers together. – Hector Sosa Jr May 4 '11 at 3:12

This sort of thing varies hugely from place to place. At my current site, the line between developers and DBAs is very blurred indeed - we (DBAs) write PL/SQL too, and they (developers) dissect query plans. We all see ourselves as peers, merely with different skillsets and responsibilities. This is very amusing: recently the company has jumped on-board the DevOps bandwagon. The database community don't understand this at all; we've always worked like that. Needless to say we are enormously productive working like this: the database tier is by far the most reliable part of the company's technology stack, it's easy to operate (since we have the skills in the DBA team to understand the application at a deep level, and the developers have the DBA exposure to understand 24/7/365 operations and how to structure their apps for it).

But I know what you mean when you talk about the "wrong" sort of developer. He's self-taught, which in and of itself is a noble thing, but along the way he's picked up a distrust of any sort of formal instructions. He doesn't know what he doesn't know, and he resents anyone trying to enlighten him, he sees it as an insult to his self-learning skills. He's learnt the imperative style of programming, because you can learn it without any of that theory stuff that CS types are always babbling about (well, badly; everyone needs to know big-O and similar bits of theory). He's learnt a bit of OO too, just because he has to to use Java. But a good database professional - developer or DBA - has to be comfortable thinking in a declarative style, thinking about set theory, normal forms, even being able to understand the relational algebra and calculus. It's very, very difficult to communicate with these people, because they are actively hostile to anything that might jolt them out of their comfort zone, which is by and large confined to how to format something on a web page. If they think about databases at all, they think that a table is like a class and a row is like an object. These guys will literally just do SELECT * FROM TABLE and filter and sort the results in their own code. They really, really don't understand why a database is better than a flat file (and they not-so-secretly think anyone who uses a relational database is an idiot).

Let me give you a real example: recently I was talking to one of these types about the issues involved in rolling back a release of our software after it had gone into production, if an issue had slipped past QA. I explained that while we might roll back his application (one of many accessing the database), it would need to be able to operate with the database still deployed. He asked why, and I said, well, in those new tables and columns, there will be real customer data. He then said, so just copy it into a temporary table, what's the problem. I stared at him in disbelief: when a customer calls and says, my money has disappeared from my account, what do we tell him, that it's OK, it's in a temporary table? He simply didn't get that when you are dealing with other people's money, you have to act like a responsible adult. For all I know he still doesn't; he's no longer with us.

The MySQL camp were like this for a long time; they would say you didn't need transactions, foreign keys, etc, if you thought you did it was only because you had no idea what you were doing, etc, etc (then when they grew up, they quietly added them in). These are the kinds of people ORMs like ActiveRecord or Hibernate were developed for, so they could write database applications without ever needing to touch SQL. Use of these technologies I consider to be a red flag - this is not a company that values DBA skills. What they really want is a babysitter...

share|improve this answer
+1 Very thorough and considered response. And I like the ORM comments – gbn May 2 '11 at 16:39
+1 for very thoughtful post, -0.25 for semi-rant against ORMs (good use of an ORM can help app development and be good for DBAs, however agree that most do not use ORMs to the benefit of both app devs and DBAs) – Andrew Bickerton May 3 '11 at 8:25
+1 for "we've always worked like that"... I'm still trying to work out what's so special about Agile/Scrum/<latest-speaker-circuit-and-book-selling-craze> – Phil Lello May 5 '11 at 2:08
Well, what about self-taught database developers and DBAs? – dezso Jun 22 '12 at 8:40
I don't really know/believe there are such kind of 'self learned' people who is reluctant to understand other people's point. I didn't met any though – zinking Aug 21 '12 at 6:24

As a programmer understanding the database better made me a better programmer. When I became a database administrator this became even more important, therefore I believe education is the key.

DBAs should patiently guide developers treating them as competent professionals. Few programmers when shown the difference between a set operation and a row by row operation on the client side will balk at the idea. We share some of the same goals - application speed, data security, maintainability, etc. This applies not just to the application logic question, but also to all aspects of database interaction. Programmers want to use their tools better and the more the DBA can show them how to use the database tool better the more they both will benefit.

share|improve this answer
Its a two way street; DBAs should be there to help guide a developer, but a developer also needs to be willing to learn. You said "few programmers will balk at the idea", and yet I can recall how MANY programmers balked at any idea that was different than what they were used to doing. At the end of the day you need to have open minded professionals in all areas. – SQLRockstar May 2 '11 at 12:04
@SQLRockstar Perhaps I've been spoiled with too many open minded developers. Obviously, your mileage may vary. – Leigh Riffel May 2 '11 at 14:32
I think I agree with all that you have said, but what is it then that is the cause of the conflict - is it the process? Are DBAs stretched too thinly to be involved this intimately with developers? Are we sometimes too lazy to do it? – Jack Douglas May 2 '11 at 15:03
yeah, and perhaps i have been burdened with too many developers set in their ways! – SQLRockstar May 2 '11 at 15:25
@JackPDouglas – I don’t know if the source of the conflict can be pinned down without looking at a specific situation. Lack of time and laziness are good possibilities. Tradition, management mandates, incorrect information, and short term gain exclusivity are just a few others. – Leigh Riffel May 2 '11 at 19:20

No matter what infrastructure we support, we have to support the users of it. A lot of users are developers, so we support the developers to enable them to make the best possible use of that infrastructure. To be able to do this we need to understand each other, with the different ideas and points of views in mind. Having insight to the views from both sides helps to make things better for the business and that is our combined goal. Make IT support the business as effective as we can.

In many organizations we see some dba types running in god mode. Most of the times these are not the ones that score very well if competency is measured ..... Often they just hide their - lack of - knowledge behind a wall of words.

To my opinion it has nothing to do with being 'programmer friendly' more with being professional. For a dba it means we need to be able to explain why we do the things we do and be prepared to at lease reconsider decision if it helps, without loosing the normal goals like availability, scalability, recoverability and performance. For the programmer it means he has to communicate to the dba, sometimes to teach the dba, sometimes to learn from the dba. My motto on this is: let the first day that I don't learn a thing be the day that the coffin closes above my head. Normal collaboration, having combined teams with developers and dba's certainly help make things easier.

share|improve this answer
I hope you learn something on that day too :) – Jack Douglas May 2 '11 at 15:05
thanks, could be something like the light in the fridge ... ;-) – ik_zelf May 2 '11 at 15:41

I think part of the problem is perspective. Dbas and data analysts and database developers have to deal with the data over time. Application developers are concerned with how to make things work when they send it to production. They don't worry so much about what the data will look like in six months as long as there are no errors when it is deployed.

But data people have to live with the results of short-sighted decisions that cause the data to lose integrity or cause duplicate records to get inserted and then try to explain why the data is bad. DBAs are the ones who have to deal with the performance problem from the process that worked fine when there were only a thousand records, but now takes hours with 100,000,000 records.

Databases are harder to refactor, so DBAs are concerned with getting it right the first time. Developers see no problem in refactoring down the road.

Developers see no problem with making the database act as if it was object-oriented, database people know that is not the most effective or efficient way to store or get the data.

Application developers often only deal with a small subset of records but not with large data imports/exports or reporting. Things that work fine to enter one record, don't work when you are talking about importing a million. Business logic in the application (which is often not accessible to the reporting application) doesn't help the report writer get the same results for a million records as what is shown on the screen one record at a time.

Another part of the problem is disrespect on both sides. I have met more than a few application developers who think data work is not hard or interesting and who believe that you would only do this work if you can't hack it in their world. People tend not to react well to being treated as if they are stupid and useless. Some DBAs on the other hand tend to treat application developers with disrespect as well and tend to put their tasks of reviewing what the developers are doing to the database as a low priority (which when you have large complex production databases, it may be). They can refuse to hear or be responsive. Who wants his whole project put on hold until the DBA reviews it two weeks later? And then he tells you it is unacceptable and you have to rewrite the whole thing?

share|improve this answer
+1 useful and interesting :) – Jack Douglas Feb 15 '13 at 2:18
Did you mean "...who think data work is not hard or interesting..."? – Nick Chammas Feb 15 '13 at 7:35

Over the many years since I started with SQL Server (1998), I've had many developers tell me how to do my job. It's interesting that they all know more than me as well being superb .net developers. In fact, they're architects too and should be doing greater things than code monkeying.

Perhaps that's the wrong attitude from me: but it's a quite common developer attitude in many shops. They do it to each other too, remember: watch the fights start when you suggest peer reviews.

I'll leave the fixes up to other answers (I agree 100% with the 2 so far) but add that the management and shop culture must support and nurture collaboration too.

share|improve this answer
Interesting you should say .NET developers - not a knock on .NET which I have a lot of respect for, but in my time alone, I've seen apps start out on the desktop in VB or whatever, then Perl CGI scripts, then maybe ASP or Cold Fusion, then JSP, then I dunno, Rails or whatever... Meanwhile that old PL/SQL code written on Oracle 7 is still faithfully processing transactions in Oracle 11g 15 years later. Devs just want to make work to justify their jobs. Me, I'm too busy adding value to the business to go on reinventing the wheel. – Gaius May 2 '11 at 17:12
@Gaius: was meant to be tongue in cheek. I've no experience of, say, a python monkey though. I've mostly been in MS shops with some Java (large corporates so predicatable technology stacks), so most uppity code monkeys are .net ones :-) – gbn May 2 '11 at 17:19
@gbn just making the point that the technologies around the database constantly change and apps that fulfill the same business needs are constantly rewritten - the database is the only solid foundation. – Gaius May 2 '11 at 17:45
@Gaius: That sort of condescension is a good illustration of how these relationships break down and we end up with pissing matches between devs and DBAs. While it's true that client technologies change more often that DBMSes, that doesn't make devs or the work they do any less valuable to the business than what you do. I'm not defending frivolous rewrites, but saying that "devs want to make work to justify their jobs" is a mischaracterization, and mean-spirited to boot. Try to be part of the solution, here. – Brian Sullivan May 2 '11 at 22:04
@Brian I am referring only to the developers who refuse to use stored procs for frivolous reasons – Gaius May 2 '11 at 22:09

As a developer, all I need from you is to know how you want me to communicate what I need. If I am asking for something ridiculous, I need for you to tell me - and if you tell me so, I will believe it because you have a track record for integrity. If you don't understand what I am asking for, take the time to explain to me what you think I mean - and I'll take the time to listen.

... Common theme, right ... Communication ... communication ... communication.

There is really no better way to put it. Developers get ticked because, "that DBA told me it couldn't be done - I sure proved him wrong last time." DBAs get ticked because, "that developer doesn't understand what I have to do every time he changes his specs."

Developers and DBAs, as @Rolando stated, have to understand each other. When it all comes down to it, we both speak "Ones & Zeros" - you'd think that would be a good match. We have 2 realms of responsibility: DBAs have data, Developers get the rest of the computer. But without data, programmers really wouldn't have much to do.

We don't have a DBA and it is painful at times. That piece of me that wanted to be a DBA a decade ago will cringe when I see some of the things we do. If we hired a DBA tomorrow, I think I would kiss the very ground he/she walked on.

share|improve this answer
+1 for Communication and Integrity. – Leigh Riffel Jun 2 '11 at 2:14
+1 for Candor and Honesty. I would not want to kiss the ground. Maybe just wash the feet !!! – RolandoMySQLDBA Jun 3 '11 at 19:34
@Rolando: believe me, I'd kiss the ground and wash the feet. We have an actual production table named '1'. – IAbstract Jun 3 '11 at 22:01
Where to send a CV? :D – dezso Jun 22 '12 at 9:04

In some companies, perhaps many, product development has a tendency to ignore anyone not writing in a compiled language. Come release time, there is resistance because network admins, DBAs, system admins, user-support, etc. each has their due-diligence to complete. There are often headaches because key aspects of the environment weren't considered. This naturally causes tensions between teams.

Who's to blame here? Ms. Communication.

Developers need to understand the environment code will be deployed in. People need to be given fair warning to adapt. Where the environment can't adapt for whatever reason (security, equipment, policy), the software needs to adapt. If this happens during the design & implementation process, everyone's happy. If it doesn't start until deployment time, it's a world of hurt.

Yes, the teams need to talk (and listen) to each other, but the project/product manager needs to create an environment this can happen in.

I've been lucky, in most places I've worked, mutual respect and communication has been part of the culture.

share|improve this answer
I'll also point out that time is often not allotted inteh schdule for DBA's, sys_admins etc to do any kind of due dligence and that even if they are asked to do so, it is useally just before launch when it is too late to suggest a change. – HLGEM Feb 26 '13 at 22:01

One thing a good DBA has to understand is the politics of data. I taight database programming and design to seasoned programmers and a few drafted DBAs for a few years. One question that would come up regularly was this: how come all the databases back at my shop are so political?

Here was my standard answer: If the database is useful, then you're sharing data. If you're sharing data, then you're sharing power. When power is shared, politics happens.

It doesn't matter whether you love politics or hate politics. If you're going to do good database work, get used to it.

Incidentally, some of you have only worked in a development environment. There are DBAs who work on the production side of the fence, and have little interaction with developers. You might think there's less politics over in production. There's more. The big production databases tend to be enterprise wide and mission critical.

share|improve this answer

A little humility might help for some of you. ;)

There are obviously valid arguments for either approach, I suggest you start by recognizing that. Software development is all about making the right tradeoffs. If it is a two way street, perhaps DBAs should keep an open mind as well.

share|improve this answer
But that's simply not true. We not talking about fashion here, but about computer science. – Gaius May 2 '11 at 16:53
Your statement is true only to the extent of the DBA's lack of work experience as a Developer. If the DBA was a developer earlier in his/her career, problems should be minimal and infrequent. The more naive a DBA is as to Developer's needs, the more respect a DBA has to work on having for Developers. – RolandoMySQLDBA May 2 '11 at 18:04
@RolandoMySQLDBA Both parties deserve respect; both are essential to successful deployment. – Phil Lello May 5 '11 at 1:52
@RolandoMySQLDBA - you repeat this a few times. You are so right that I can't even imagine how to be an effective DBA w/o prior developer experience. I consider myself being in the phase of switch between the two - well, at least thinkingwise. – dezso Jun 22 '12 at 9:10

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

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