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.