Brian Madsen wrote an interesting post following Greg Linwood’s presentation at my home user group, the Perth .NET Community of Practice. I would like to make a follow up comment on this as I have a slightly different opinion to Brian:
When it comes to an application that uses a database there are a number of roles associated with building that application. I don’t want to get into the nitty gritty of what the roles are called but essentially they fall into a couple of broad categories IMHO.
- Interaction Designer: This role is primarily responsible for building the front end application such that it is usable, presents the information in an appropriate format and will get good user adoption. NB: This function is actually where a LOT of applications fail!
- Developer: This role is responsible for coding the business logic for the system – extracting and manipulating data into a format that can easily be consumed by the user interface. Quite often this role is merged with the Interaction Designer role but in large projects there are quite often coding tasks that just require manpower to get classes written that serve a particular function. NB: Most of the code this role rights should be easily tested using Unit testing. This role should NOT be concerned with how indexes are structured etc, rather they need to define what data they need to retrieve and update.
- Database Designer: This role is the only role that should be concerned with what indexes are on the database. If an application is performing badly (at the data tier), it is NOT the responsibility of the developer to reindex the database. Through collaboration with the developer (ie the user of the data) the database designer is responsibile for structuring the database such that the developer can work with the data.
- Database Administrator: IMHO this is an operational role and if an application has a good SLDC then the database administrator should NOT be reindexing. Any changes to the index should be applied as a new version of the application. Of course, this doesn’t hold where a database is being used by multiple applications and is not being versioned in line with the application. Regardless, there should be some lifecycle management around any changes that are applied.
There may be other roles/points that I haven’t considered, so please feel free to add your 2 cents worth 😉