views:

359

answers:

12

In my experience, this has been a contentious issue between "backend" (database developer) and "frontend" guys (application developer, client and server side).

There have been many heated pub discussions on this subject.

I just want to know is it just people have different mindsets, or lazy to learn more and feel comfortable in what they know, or something else.

A: 

I believe it stems from the fact that programming in sql looks easy, and to get started you have to have a small amount of knowledge (Really for a programmer to learn SELECT * FROM Table is pretty easy). Application programming is not the same way. It becomes very complex in a small amount of time, and that discourages a lot of people. Now I am not saying that database people are any less intelligent it is just what they do looks easier than building applications.

Kevin
It is not though, a database person would not use select * especially in code that will go over a network or be used multiple times.
HLGEM
Right that's my point. On the surface it looks easy to be able to build queries that will "work". It may be poor, but it gets the job "done" and that's why so many programmers jump into db development. The level of effort vs. basic results is low.
Kevin
+2  A: 

Because programmers very often must understand and interact with databases to do their job, but DBAs very often don't need to do any programming (outside of the DBMS) to do their jobs.

mbeckish
+1  A: 

If you develop applications, then the chances are, that sooner or later, you'll have to connect an app to a back-end.

The opposite is not as true.

Galwegian
+10  A: 

It is about levels of abstraction. A database is the lowest level of abstraction in a typical business application (software-wise). It is much more likely that a developer working on an outer layer of the abstraction would have knowledge of an inner layer than a developer in an inner layer would know about the outer layer.

This is because inner layers of abstraction best perform when they are ignorant of the outer layers who depend on them.

So a designer in the presentation layer of a website may know a bit about the server-side code they depend on because they interact with it. But the developer working on the server does not need to know anything about design at all.

Andrew Hare
+1  A: 

I think it stems from necessity. If you consider the roles of each person, a programmer needs to to database related stuff far more than database workers need to do programming tasks.

keithwarren7
+16  A: 

I might re-phrase the question: why do (some) application developers think they can do "database stuff" without actually bothering to understand it properly? Whereas database developers do not (in general) assume they can write a good application without some training and experience!

Tony Andrews
+1 very nice - we developers can be prone to hubris in this way
Andrew Hare
Wow - my fastest "nice answer" badge ever! I cannot only assume this subject touched a raw nerve in a lot of database developers!
Tony Andrews
... "can only" I meant of course
Tony Andrews
+3  A: 

I would say it's on a need to know basis. Applications developers often need to know how to connect to databases, add records, delete records etc... This is taken further with new technologies such as LINQ where developers can write database queries within their actual code.

Database developers on the other hand only really need to know how to write database queries as that is their job and probably won't need to worry about the code at application level.

cyberbobcat
A: 

From my experience, having developed both "databases" and "applications" (following your nomenclature...), I guess there's a big difference in state management.

Properly designed databases are always in a "clean" state, and every transaction keeps this consistency. So when developing a database, you have to very clearly specify your data abstractions into tables and which updates are legal and so on.

I've found that most application developers (myself included :)) do a very sloppy job in keeping this consistent state in the application. Any non-trivial interface has many more possible states to manage than a modest database, and it's not as easy to make sure it's always in a clean state. It's also harder to analyze every possible sequence of steps that users will perform.

João da Silva
A: 

From my experience, the application developers don't do all the database stuff. Consider all the administration that is related to the databse, backups, replication, etc.

A typical DBA (at least on most of the projects I've been involved to) takes care about everything that is related to project databases - all administration, cooperates with application developers on performance tuning, gives advices about SQL used by the app, does some of the stored procs coding, creates (or, at least reviews and consults) physical DB designs, etc.

So, aren't the database guys "lazy", or "fine with what they already know" just from an application developer's perspective? I'm an app developer myself and there is a whole lot of things that I just don't know about the DBs we're using on our projects.

david a.
A: 

Part of my education ensured I got a decent understanding of how Databases work. I went into the field expecting to do database work, and a lot of it. I'm a web app guy; it comes with the territory I guess.

My two jobs as a developer have been at two shops that would best be described as tiny (2 people myself included, and then just me) and tiny (3 developers, briefly having a fourth). I have not observed an immediate business need for, nor worked anywhere that had the resources to employ a dedicated DB guy. I can envision some scenarios where that would change (including a new job :P).

As to the rest, I agree that abstraction is also a factor and as developers we're way up on top/outside looking in. I can't imagine doing web app development without DB skills, and I consider Sql/DB Management to be both an important tool and an area I need to stay sharp in.

I'll add that I treat the database side as its own field. There's skills that translate between the two, but there's a lot of specialized knowledge I need to acquire to get better at it, and that being a good programmer doesn't necessarily mean I'm doing a good job on the back end either (fortunately, I'm not a good programmer ;) ). Also, I'm pretty sure that's what she said.

peacedog
+1  A: 

2 reasons:

  • DB Vendors facilitate bad SQL, and
  • SQL is hidden from view while application UI is front and center.

Most naive developers think SQL is a procedural language and write it as such because vendors ensure that the tools exist so that they can do so. DBAs know that good SQL is set-oriented and has optimization principles that are totally different from those involved in application programming.

The visibility aspect makes it so the application developers can write bad SQL against a database and get it to perform in a marginal way, and no one ever sees quite how bad it is. When a DBA writes an application, there are immediate critiques on its appearance and behavior because it's directly visible to the end user.

mwigdahl
A: 

Good question. Actually why developers do Database Stuff because where no dedicated Database guys then developers have to do that. But a company have Database Guys also have Development guys.

:) what is your idea ?

Kashif
Based on my expeience where database guys don't tend to look at the design of the system from all angles. They feel it's not in their job to do so.I am happy to learn both sides and can come with better solutions by doing so.
Ferdeen