Re: company database architect that doesn't like rdbms?

  • From: Stephane Faroult <sfaroult@xxxxxxxxxxxx>
  • To: robertgfreeman@xxxxxxxxx
  • Date: Fri, 13 May 2011 09:35:49 +0200

Robert,
Then they use tools like hibernate that inherently make for in-efficient interfacing with the database, use procedural processing instead of group/set processing and don't write tuned SQL code and have the gaul to wonder, why is the database so slow.

Sigh..... I love developers, I really do..... but they need to be taught..... they need to learn. That is the point in some senses of my DBA 3.0 series on my blog (which I need to post part three on).... that we as DBA's are somewhat responsible for this. We have not been evangelests, we have not sold our wares, or taught the lessons that need to be taught.

Have we really been good stewards of our knowledge? That is the question.


While I agree with the diagnostic, and as someone who has been doing, and is still doing, like yourself some effort to educate the masses (if you search for "oracle" on Youtube you'll usually find me ahead of your employer), I am not sure that grass-root-level guilt is the way to go. For one thing, I'd lay squarely a large part of the blame on vendors themselves and the marketing discourse, "the database will fix it automagically" approach, the supposedly bright ideas to do it that, in the long term, proved to be not as bright as intended (CURSOR_SHARING=FORCE, anyone? But of course we can't review the code and use bind variables where needed). While acknowledging that a handful of people, the most visible of whom is probably Tom Kyte, have always advocated sound coding practices over the use of presumably clever features, I am not sure that this is the discourse that CIOs have heard. I'd rather think that they have heard that any idiot can "persist" data in a database, and that if they spend enough bucks on Exadata and the like, "their" applications will fly even with cheap outsourced coders. "You won't need to touch the code". Yes, and that's precisely the problem. One day, the code will hit the fan anyway.

The problem is very deep. It starts at the university. I have seen on a French forum a student talking about what his DBMS professor had said, which was hotly debated; there was not enough context for me to decide whether what the professor had said was wrong or not. Anyway, the student defended the lecturer by saying that he was the CIO at the main site of a major French corporation (which he named and which is known all over the world). I presume that this man's latest hands-on experience of a DBMS dates back to the days when he started in the trade as a young IMS/DL1 developer. The problem isn't only French. I've taught in a Canadian University a long time ago, some CS professors only logged into systems to enter grades. In some of the database videos posted in the internet by the prestigious Indian Institutes of Technology the lecturer explains subqueries with the example of a correlated IN () (uh?).
I dare not imagine what is taught in lesser educational institutes.

There is also a growing disconnect between infrastructure, to which DBAs are usually attached, and development, made even worse by the cloudification. Although both are turning in their own ways to a point-and-click affair, if you show the OEM graphs to a developer he or she will not be able to make much sense of them (and I am often led myself to wonder what kind of action they are supposed to trigger). Conversely, most DBAs are not competent programmers - and I have no problem with this, it's a different job. If job ads always refer to "SQL tuning" in the requirement list for DBAs, it usually means "spotting the missing index or unused one" and not much else. My own vision of SQL "tuning" is usually rewriting queries, and sometimes a whole process, from scratch after understanding the initial intent, but I don't consider it a part of a DBA job. And the bigger the company, the greater the disconnect. If some of us still have on their shelves, and still open from times to times, "The Art of Computer Programming", we are in a minority - and when I say "we" I can include DBAs (normal) and developers (ouch). I no longer count the number of crisis-meetings-to-fix-performance-issues with DBAs saying that the number of buffer busy latches was much too high to developers who have trouble understanding what a pointer is (only 40% of programmers understand pointers according to Joel Spolsky). Wasted time. I have never seen anything more fruitful than sitting next to a programmer, recoding part of the program and showing the difference.

I agree with you that any little thing a DBA can do to explain how things work to a developer helps. But it's just a drop in the ocean.

--
Stephane Faroult
RoughSea Ltd <http://www.roughsea.com>
Konagora <http://www.konagora.com>
RoughSea Channel on Youtube <http://www.youtube.com/user/roughsealtd>

Other related posts: