I worked at a university as a data analyst using statistical software in 1983-- yes, 1983. I struggled to manage data relationships using SPSS. Then I was introduced to Ingres 1.0. Relational database has been my credo and my paycheck since then, with statistical software and Excel in supporting roles. Even though the Ingres database server crashed too frequently and it was my job as DBA to recover from crashes and work to prevent them, I was recognized as knowledgeable about data as well as database server. I taught relational database design and index design for Computer Associates in the mid-1990s.

I work on short term contracts, mostly fixing SQL Server problems created by application developers who may be good application programmers, but not database programmers. Microsoft created a monster by presenting SQL Server as a room in the Visual Studio rather than supporting the role of the DBA as separate from the role of application developer. True, the programming built into SQL Server eliminated the need for a dedicated DBA to manage the database server and databases, but what role understands the data relationships? Typically, application developers do not recognize or respect many-to-many relations-- for instance. A data-oriented DBA is a much better database designer than is the combination of a business analyst working with an business-intelligence-challenged application developer.

Companies that hire me typically expect that I will make a fix to how SQL Server DBMS works on Windows and their hardware -- "tuning." Typically, they don't welcome a demonstration that performance can be improved dramatically by teaching database programming to their application developers. (Really now, do you think it's more likely SQL Server and Windows fit together badly or that your application is not using SQL Server optimally? How many programmer analysts does Microsoft employ, and how many big applications has your lead developer delivered?) Object-oriented programming ("data is dead but must be persisted when not being viewed through this application") and security-mandated separation of development from production have pretty much succeeded in persuading IT managers that data is owned by applications and the database is just a box.

>>Will the DBA role evolve naturally from being a "caretaker of data", to "interpreter of data"?

I would like the DBA role to RETURN to include "interpreter of data."