10 May 2007

Wherefore art thou, Development DBA?

Highlander Doug Burns wrote a great piece last month entitled "What use is a Development DBA?" that really hits home for me. I have a lot of minor and not-so-minor conflicts with the developers on my team (read about "the compound keys" for some perspective).

As Doug says, a lot of the problems could be avoided if developers leveraged their DBA earlier in the design process, rather than sending him a SQL script to run on release night and having the DBA sigh at being relegated to an overpowered operator.

I'm making more of an effort to track down poorly performing production queries and filing friendly bugs for developers with suggested fixes (normally an additional index). But we could do a lot more by having proactive sessions and getting the DBA involved in testing to find these queries before they get into production. Often times I'll get a reaction that the developer had no idea that such-and-such was possible, and I remind them that I'm "right over there" and to feel free to seek me out for any and all database and application design questions.

Of course I'll still be grinding my teeth when I think of those huge compound primary keys polluting my database.

1 comment:

  1. Karl ReitschusterMay 24, 2007 at 7:05 AM

    That's really true. I started with a .NET developer team creating a CRM system. And had a great influence on the OR-Mapper- the database design and the backend interfaces.

    We usually need the production dba only to get to the next sotware release level.
    All design and performance issues are solved during development.
    Thats all!
    Karl

    ReplyDelete