When I interview database candidates, I want to asses their skills in three different areas; how well they can set-up and maintain a database, how well they can program to a database, and how well they can design database systems. These coincide with the three roles I would typically hire: database administrator, database programmer and database architect. Even though I am hiring for just one of these roles, and I don’t expect any single candidate to be fully proficient in all three areas, I do want to understand the breadth of their exposure. It is an indicator of how much empathy they will have for their team members when working on database projects, and understand the sometimes competing challenges each faces. While there will always be some overlap, the divisions of responsibility are broken down as follows

  • Database administrator – Installs, configures, manages the database installation. This will include access control, provisioning and patch management. Typically provide analysis into resource usage and performance.
  • Database architect – Selects and designs the platforms, and designs or approves schema. It’s the architect’s responsibility to understand how data is used, processed and stored within the database. They typically select which database platform is appropriate, and will make judgment calls whether or not to use partitioning, replication, and other advanced features to support database applications.
  • Database programmer – Responsible for coding the queries and use of the database infrastructure. Selection of data types and table design, and assists with

We talk a lot about database security on this blog, but we should probably spend more time talking about the people who affect database security. In my experience database programmers are the least knowledgeable about the database, but have the greatest impact on database security and performance. I have been seeing a disturbing trend of development teams, especially web application programmers, who perform every function in the application and regard the database as a bucket where they dump stuff to save application state. This is reflected in the common choice of smaller, lighter databases that provide less functionality, and the use of abstraction techniques that clean up the object model but lose native functions that benefit performance, data integrity and security. Worse, they really don’t care the details of how it works as long as their database connection driver is reasonably reliable and the queries are easy to write.

Why this is important, especially as it pertains to database security, is that you need to view security from these three perspectives and leverage these other practitioner skills within the organization. And if you have the luxury of being able to afford to employ all of these three disciplines, then by all means, have them cooperate in development, deployment and maintenance of database security. You architect is going to know where the critical data is and how it is moved through the system. Your DBA is going to understand how the databases are configured and what operations would be best moved into the database. If you are not already doing it, I highly recommend that you have your DBA’s and Architects do a sanity check on developer schema designs, review any application code that uses the database, and provide support to the development in team access control planning and data processing. It’s hard to willingly submit code for review, but better fix it prior to deployment than after.