Is your IT team conducting an internal feud, with team members struggling against each other instead of fighting the real problems of limited time, money, and manpower to support your organization’s technology needs? Buck Woody argues that you can’t afford to become the Hatfields and McCoys. Also, both developers and DBAs have merit in the IT team. Although different, both jobs are crucial for a successful enterprise. However, conflicting responsibilities sometimes trigger members of the two related professions to face off. Baya Pavliashvili points out a few common situations that can cause tension between the two groups and provides some advice for working your way out of an argument before it leads to a war.
DBAs vs. Developers: How to Collaborate
About The Author
Eugenia Loli
Ex-programmer, ex-editor in chief at OSNews.com, now a visual artist/filmmaker.
Follow me on Twitter @EugeniaLoli
and abstract away the database technology.
Nothing more than glorified users running Excel. They get in the middle of the development process, come up with foolish rules like how the database object should be named, how the stored procedures should be written, etc. They could not write code to save their lives (which might be why they are DBAs) and yet they absolutely thrill at being able to push developers around with data.
It is this kind of nonsense that forced me to cut them out of the development process altogether with files and embedded databases that CANNOT use a DBA.
I work to eat, not looking to rewrite the world, just do my part. These people are too often willfully obstructive. Let’s go embedded. Down with DBAs!
Let’s go embedded. Down with DBAs!
Yeah… that’s really going to work if you have to do a serious banking application needing distributed transactions, a long and growing list of business rules, and mission-critical data integrity.
I’m sure there are plenty of applications that can be done without needing a DBA, but some of you developers need to learn that for many serious companies, their data *is* their primary asset, and it needs to be preserved no matter what is going on in application space. A proper database design means the data lives up to the business requirements of the company, no matter what the application(s) are that interact with it.
It’s kinda like the difference between having cash, and having money in the bank. While you have the cash, chances are you can misplace it, be robbed, have it burned up when your house catches fire, whatever. In other words, if you behave with faulty logic, your money can be lost, AND your money can be lost by pure random accident dues to the instability of an individual life. But, if you put your money in the bank, it suddenly becomes more than just a collection of objects you can hold in your hand. Now it plays by rules that are well-defined and distributed around the country, and don’t depend on your daily mistakes or caprices. And, even if your whole neighborhood blows up, you (having excaped the blast) could walk into another branch and withdraw money the next day.
Good analogy. You’ve sold me on databases. But still in my experience (which could be based on a biased sample) the majority of DBAs are obstructionist or secretive and like to cover themselves with jargon.
Just my experience, and I’m not a developer. I’m a network engineering manager.
But still in my experience the majority of DBAs are obstructionist or secretive and like to cover themselves with jargon.
I am primarily a developer, not a DBA, but I work very hard at taking a DBA-like approach to my database design. Yes, there are definitely DBAs who meet your description, but also, it doesn’t hurt to remember that these guys are paid to jealously guard a company’s data. And that doesn’t just mean making sure a table isn’t dropped, but making sure that constraints are not violated, and data is prevented from corruption due to logical mistakes. This is serious stuff, and I look at it akin to being an air-traffic controller. In other words, their company is relying on them to be right, and it is *critical*. Stressful, I would think, so I try to cut them some slack ;-).
But yes, anyone can be an idiot. Ideally, both developers and DBAs would have a clear understanding of the value of set-oriented logic, and the relational model of data. But, it’s pretty bad out there, and I meet almost as many DBAs as developers who have serious gaps in their knowledge.
There’s a good additional comment on where to put business logic for big honking applications that run on big honking databases.
For those who can’t be bothered to RTFA* with comment, He basically says that business logic is generally best left to the middle tier, except when consistency is required among many VARIED clients. In this case, more business logic should be pushed into stored procedures, triggers, etc. He also correctly states that the downside of this is that porting to a new database becomes more difficult. Basically, as more code is witten using your DBMS’ particular FLAVOR of SQL, developers are more likely to use vendor specific language extensions either for features or performance.
Unfortunately, he is a little off base with regard to client side business logic. You do need more than data-field validaton, especially if generating reports, or passing specifically transformed data to others. There are reasons nearly all parts of Office (the ULTIMATE rich client) have had database connectivity for years. Why should server resources be wasted with generating PDF’s or fancy graphs when you can just make the client do it? And don’t tell me that you can’t have a rich client inside of a web browser. This is the age of the Web browser as platform. We have Java, Flash 8, AJAX, SVG+Javascript, and other squillions of ways to have rich client experiences while using fewer server resources (just send the data).
Ok, rant over
–JM
Everything is a compromise and generally just listening more than talking can get over most developer issues. I’m primarily a developer, but I’ve dabbled in DBA stuff as well. The problems I’ve seen (and been guilty of) is just not understanding the other side.
Basically there are assholes on both sides. Intractible assholes generally. You can’t work with them and you aren’t allowed to beat them to death. They have their way of doing things, which is so totally, insane, irresponsible, stupid and inpractical. They don’t seem to get your point, no matter how often you repeat it. Generally because “Thats the way we’ve always done it” or “It works, so I don’t see the problem.”
I’m just taking deep breaths, developing my apathetic carapace, and letting it go. It’s not worth pushing the issue. The chances of getting through to non-technical management are pretty much zero. The worst case being where extra hardware to overcome performance and or reliability issues was considered “cheaper than extra development time.” Its a lot worse when you are an outsider to boot.
As a developer I try to keep abreast of new technologies and techniques. I profile my code, I make lists of design weaknesses and potential bottlenecks. Not that anyone seems to care.
Hmm, database design through loving kindness. Hey, great idea. If we designed an airplane like that will you fly on it?
In all these types of discussions, it occurs to me that there is a major missing element: everyone talks about developers and DBAs, but never about that rare creature known as the Data Modeller. DBA means “Database Administrator”. According to this title, that person’s job should be the database equivalent of the Unix system administrator. In other words, someone who knows how things work, and how to make sure it keeps doing so, but not someone who actually creates the operating system in the first place.
Of course, what really happens is that informally, some DBAs or developers are just expected to be data modellers, and obviously some of them can well qualified to do this. But, the concept is not too well formalized, nor are many companies aware that establishing a proper data model can happen before either developers or DBAs get in the mix, and can thus forestall these sorts of quarrels. It should be the second step after the business requirements are established.
Why bother to understand a schema. Just add fields and tables as you desire. Why bother to think about the long term usability of the schema when adding this field here and that field there and this table here and that table there will make the code work today.
Geeze the db runs slow. instead of figuring out the problems, lets create a table but only have a subset of the data so the query goes fast. Then lets create 3 or 4 duplications of the data throughout the database so that when Bob’s query runs we get one result set and when Janes runs we get another. Then what the f*ck is the DBA doing that we have such wierd results.
Geeze I cannot put this crap data into these fields, I’ll just drop the foreign keys and now it works. One bug fixed.
Views indexes, we don’t need no stinkin’ performance and nomalization.
mark mcginnis
Isn’t this the DBAs job, to make sure that the database schema is kept clean?
This is why if there must be a DBA they must to be part of the DEVELOPMENT team and go to the development meetings, etc. Let IT do backups and restore. It is THE reason that you are having trouble with _those_ developers. Your organization does not know which side of the fence you should be on.
Most DBAs discover, though, that there is more power and money in claiming databases and whining about developers. It is way too common.
What about that be a dynamic process? Ususally, after some time (probably longer when things are really well conceived), the structure must be refined/extended, be it because new needs arrived in the infrastructure, middle or interactive level. At this point, we already have a lot of people involved (DBAs and developers).
DBAs prey on the fears of the organization, “You will lose your data,” or “There will be a security breach” while the database is the one-stop-shop for crackers… all the data in one place, all in plain text. Brilliant.
Putting logic into the database is another dumb idea. Why create a middle tier and then try to put half of it in the database? Now the DBAs all chirp together, “It runs faster that way because the proc is pre-compiled and the … thing … has a … and (mumble) … (eep).”
A single select running in the pre-compiled context of a stored procedure is faster but NO ONE does that. They create whole progams of protective steps in the database. Now it is slow. Must be the stupid developer!
Right.
One of the key pieces left out of this equation is the System Administrator. The guy (in well designed IT orgs) that provides the environment and the resources for the database and for development. I cringe having to come to work as an SA under the management of a Developer. Developers do not have the first clue on what it takes to build and maintain a successful computing environment neither do DBA’s for that matter. Anyway the DBA developer relationship means nothing without a System Administrator in the mix and maybe even a network guy.