Why Application Developers Think Differently Than DB Developers

It is all about programming practices. Very early in their training application developers learn three important paradigms:

  1. Generality – Solutions should work in as many new situations as possible
  2. Premature optimization is the root of all evil
  3. Goto considered harmful

These are very good programming practices that work great in many development situations. Except when it comes to databases. With databases, the first two practices are trouble. Here’s how:

  1. Application developers want their code to be very general and adaptable. So, they can’t depend on any vendor specific DB features. This mostly means that the developers will be forced to reinvent the wheel on every step of the way, or write a huge, expansive database layer, or even worse – use Hibernate.
  2. More generality: Often application developers think that the idea of having separate tables for different conceptual objects and different columns for specific attributes of these objects is a form of evil hard coding. Their solution will be to use few “generic” tables, like this one:
    create table things (thing_id number,
    thing_name varchar(4000),
    thing_value varchar(4000),
    thing_data_type_id number);

    Or sometimes, they will add columns named userdata_1 … userdata_n to an otherwise well designed table. Just in case.
  3. Of course, if someone will point out that their design will never scale and will cause the application will run very slowly, the application developer will scoff “This is premature optimization! Knuth said it is evil! If it will be slow we will get the DBA to add few indexes and buy more memory”.

DB developers have a different view of things. For us, performance and scalability are not features number 18 and 27 on our list. For DBs performance and scalability is everything. There is no other reason to even have a DB, not to mention an expensive one like Oracle.

No optimization is ever premature on a database, and we prefer to start optimizing when we do the design and modeling. The question “which way is faster” is usually asked when we try to decide between several design ideas or different ways to write the same query. On the other hand, we optimize on an entire different level than C developers, and only very rarely resort to inlining functions and embedding assembly code.

DB developers remember very well that if the data model is good, all other optimizations are much easier. Often great queries will simply write themselves on a good model, but even when they don’t, it is easy to see which indexes should be added and how queries should be tuned when the underlying model is clear.

We also know that DBs work best on specifics. The more information about your data the DB knows, the better you can get it to perform, and also the better you can guard the consistency of your data. While application developers like to “generalizing” their programs by pretending they don’t have information that they actually have, DB developers prefer to use every piece of information they can get their hands on, and then force more information and promises from their customers.

Good DB developers are vendor specific. They know one database very well, they know all the features, limitations, concepts and behaviors. They know how to make it run very fast and how to avoid problems that can only happen on this specific DB. They can tune it to death and get maximum value out of every last feature the vendor put in. Being good engineers, we will not let this knowledge go to waste.

No wonder it is very difficult for application developers and DB developers to get along!
What the application developer considers a best practice, DB developers call a complete waste of resources and a hopelessly slow application. When DB developers talk about their best practices, application developers think this is the root of all evil.

Of course, I didn’t do justice to the topics I covered. Tom Kyte has several best selling books about how to approach database development and design. But I think I had a new insight about the source of the problem: Application developers are not stupid, they just had different indoctrination. Thought it is worth sharing.

Advertisements

12 Comments on “Why Application Developers Think Differently Than DB Developers”

  1. Wow – there is a lot of generalising in this post.

    I think the key problem with development in some cases is the lack of involvement of the right technical resources at the right time in the development process. Sometimes this means that the most time and resource efficient mechanisms aren’t used to get the job done – and I mean people, process and machine resource here.

    The end result can be that the end result doesn’t play to the strengths of the software (DB or other) that is being used.

    The key, I think, is to work collaboratively with all members of the development team, and to promote this collaboration between key parts of the team ( eg: DBA and app dev ) to utilise the product specific knowledge of the team as early in the piece as possible.

    I agree with a alot of what you say, I just don’t like to promote the DBA and application developer divide.

    I’ve been reading this blog for some time – enjoying what I find here.

    Best Regards,

  2. chet says:

    Mathew,

    I don’t think it was DBA vs. Developer, I think it was DB Developer vs. Application Developer.

    prodlife,

    I can’t say I disagree with anything you have put down. I have a similar theory that I can’t quite put into words yet.

    Thanks for the inspiration.

    chet

  3. prodlife says:

    Hi Mathew,

    I’m glad you are enjoying my blog.

    Yes, the post is full of generalizations, but sometimes these are necessary in order to illustrate a point without getting bogged down in all the different cases.

    I completely agree that projects are often managed in a way that doesn’t allow full utilization of the resources.

    I think that highlighting the differences between how different developers from different background think, and the different approaches and priorities they have can actually help to bring the teams together.

    The idea is not to promote a divide but rather illustrate how DB developers approach problems differently than the way application developers approach them.

  4. prodlife says:

    Chet,

    We definitely need to have a drink together at a conference. Seems like we have quite a bit to talk about 🙂

  5. As Chet pointed out – I confused DB developer referred to in your post with DBA.

    So, what did you mean by DB Developer and Application developer in your post?

    Have you ever seen the term DB Application developer used?

    Mat.

  6. chet says:

    I’m not getting on a plane anytime soon (yes, irrational), so you’ll have to come to one in Orlando (Disney World!).

    I’m buying.

    chet

  7. Chris says:

    There must be something in the way developers are taught that leads to developers independantly arriving at the same solution. A classic is the EAV (entity attribute value) data model, I have run accross it a couple of times and it has been thought of from scratch in each instance. usually the conversation goes something like this:
    Dev: look at this great flexible datamodel we have invented.
    DBA: oh its an EAV model.
    Dev: a what?
    DBA: google Entitiy attibute value
    Dev: I thought e had discovered something new…

    Most of these kinds of thing work fine for the specific application the developer is working on but once people start asking for reports, new ways to view the data suddenly it all gets much harder. By making the data model ‘Generic’ the data is actually less reusable.

  8. prodlife says:

    Chris,

    I think the cause for much wheel reinvention is that people don’t read enough, either on the web or physical books. So they rarely know about things that were obvious for a long time.

    I’m at fault here as well – I’ve never heard of EAV before 🙂

  9. prodlife says:

    Matt,

    In our organization they are called “development DBA” as opposed to the “prod DBA” who are the real DBAs in the organization.

    Prod DBAs do things like backups, recovery, cloning schemas, managing space, etc. They are the “real” DBAs in the organization.

    Dev DBAs do all the development that is tightly integrated with the DB – writing data loaders, partition managers, data reporting layer for the application (if Hibernate is not used), schema verifications, schema upgrades and most importantly – they do the data modeling for the application. They write in PL/SQL and Java.

    App developers are those that write the object models, develop business logic, graphical UI, XML, and all the other stuff that Java does when it doesn’t access the DB.

    I hope this is clearer now.

  10. Thanks for the clarification.

    Role descriptions are not always so clear cut where I work.

    Your definitions would put me closest to the Dev DBA – in terms of background, core skills and some activities, although a Venn diagram of what I do would show that life is much more varied, and more difficult to label.

    M.

  11. Tom says:

    Hi !

    In my company things are completely different. Since we (Dev DBAs) have so many different projects to support we always try to make the models much more generic otherwise we have to update the model for each new attribute and so on. Java developers here are usually not very generic they always try to force us their db models which are very specific, sometime for each new type of entity they want a seperate table even if the attributes are similar or the same. Taht’s what the devellopers call “verticalisation”.
    So: Different company, different situation.
    I still don’t know what the best is, to have all attributes “hardcoded” as table columns or to have these (soft) attributes better in a generic property table (beside the main tables)

    The fact is that the model and requirements here are changing very fast, another reason for me to be more generic.

    Rgs, Tom.

  12. junewyski says:

    I believe you are all missing the function of the data modeler. The data modeler should be the person gathering the data requirements to develop the logical and then physical data model that the app developer uses to code to. The Dev DBA term you are using should be the person that writes the SQL, etc for loading the tables, exporting, etc., all that prodlife stated for this role except modeling the data. I agree that one person could do all but they need to be specifically (an properly) trained and gain experience with designing the tables to ensure an optimal design.

    I have enjoyed this topic very much because being a data modeler I have had millions of conversations/arguments with developers as to why I didn’t design the table to violate the 1st normal form of modeling data and that is to eliminate repeating attributes (userdata1…userdatan).
    Thanks!


Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s