April 12, 2007 1 Comment
I find this especially interesting because “Development DBA” is a job title bucket into which I sometimes fall depending on the employer/client.
Over the last several years, I have been called Database Architect, Oracle/Database Designer, Oracle/Database Developer and Development DBA at various employers/clients.
However, at none of these places was the job wildly different from any other and the differential in job title bore no reality to any of the minor differences.
What is a constant is that at none of them was production-DBA-type-activity-but-on-a-development-database a significant part of the remit. Actually, that’s not quite true. At one site, it was a small part of the job for a while until the responsibilities fell under the operational DBA umbrella.
So, maybe I’m not a Development DBA, maybe I am. I’m not sure. It depends on the site and their spurious job titles.
Based on my experience the role of Development DBA tends to be some sort of hybrid data architect, database designer, database developer and development DBA (or maybe I’m just lucky that that’s the space I tend to occupy whatever the title).
In which case, I find the role to be an absolute vital one but one were you can struggle to exert the appropriate influence, especially if the site is not used to such a role.
The responsibilities can be:
- Schema design
- Database interface design
- SQL & PL/SQL development
- SQL & PL/SQL code QA
- SQL & PL/SQL code optimisation
- Database release scripting / communication / management
- Testing new database features and implementing as appropriate (together with negotiating acceptibility of said features with production/operational DBAs)
- Advising operational DBAs of application specific functionality / settings
- Diagnosing production issues with application specific database activity and this is done as part of the development team rather than the operational DBA team
- Acting as bridge from development to operational DBAs
What does vary from site to site is the degree to which environments are locked down (in other words how easy it is to do any tracing, parameter changes, new feature implementation) and more significantly how much influence you have over the wider application design/development, the application SQL or PL/SQL and
where in the application that data logic is. These variables tend to define how good or otherwise a place is to do this sort of work.
The ideal, for me, is a site that believes in stored procedures – not necessarily as a repository of business logic but of data logic - and letting the database store and deal with stuff that the database is best at (e.g. set operations, bulk operations, etc). The opposite is some sort of ORM driven site with generated SQL
or PL/SQL, iterative non-set, non-bulk operations and database independent feature-free code (with the inevitable consequences), and there are a whole host of places that lie somewhere in between.