Does a programmer really want, or need, to know the full details about how his code gets executed?

I'd always been rather on the side of those who think that the working programmer ought to be completely at home in the details of how the system that he is programming actually works. I rather enjoy getting familiar with SQL Server internals. I felt slightly unsure when Celko attempted to persuade me that programmers should concentrate on programming in SQL, and creating Database structures, rather than focus on a particular implementation such as SQL Server or MySQL.

It was a move to a different database system that changed my viewpoint. A move into unfamiliar territory made me think that a relational database should be able to get on without help, and execute code in the best way it sees fit and that provides good performance. If the developer finds it necessary to make implementation-dependent tweaks and hints to get acceptable performance, then he has, I think, highlighted a weakness in the implementation and also crossed over into the preserve of the DBA. PostgreSQL has many good points, but I hit the downside when, in my initial fumbling, I tried a very simple four-way join and the system took ten times as long to return the results as did SQL Server. On appeal to the expert forums, I started a long journey into the bowels of an alien system (it was hosted on Linux), led by EXPLAIN ANALYSE, staring hard at query plans, and tweaking almost everything that could be tweaked, such as configuration parameters, cache settings, postmaster options.

I suspect that the Database developers and DBAs share a great deal of interest in the query optimizer, but there will always be a divergence of interest in the more esoteric matters that affect performance, such as index statistics. Likewise, the most efficient algorithm for any operation by an application is likely to be of far more interest to the Database developer. This divergence of interest is healthy, and helps team work because there is still a common goal. When there is talk of 'impedance mismatch', 'application domains', and 'data repositories', there is less sense of shared goals here. One can often detect impatience from some application developers with relational theory, and with the value of the accumulated experience of a generation of database-intensive application development.

Perhaps the answer is that, when working in teams, developers and DBAs must always share a common culture even when they don't get immersed in the details of the work of the other; but one can harbor a sneaking sympathy for the harassed application developer who has, perforce, become an 'Accidental DBA' and is faced with a system that is obdurately slow when executing plain vanilla SQL. Surely it should just work?