Guys,
In my experience there are so many issues that come up in design that eventually affect the quality of life for a "production" dba that I have real concerns splitting the role. In my world as much as possible I do both starting with design I look at the various tradeoffs between performance (at various levels), maintenance and assist in architectural and design issues that later translate into how the database is made "physical" and therefore how much heartburn I might have with things like backups and recoveries, performance tuning and options. I work with developers in assisting in tuning SQL and this helps again in determining the best database design and understanding the tradeoffs necessary. If you do break these roles apart what is to keep an "application DBA" from doing the quick and dirty or neglecting long-term maintenance issues. They would necessarily have to deal with the "beeps" in the middle-of-the night that could have been averted due to a better initial design/architecture. To me these roles are done better if combined or at the least if the "productional" DBA type is at some level part of design along with the "application" DBA type.
