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

At the risk of being black listed, we all know what the problems are.  

What's the solution???

How did the organization get here, how do they move away, and what will it take?

Is it at the point of no return to live with and deal with?
________________________________________
From: oracle-l-bounce@xxxxxxxxxxxxx [oracle-l-bounce@xxxxxxxxxxxxx] On Behalf 
Of Stephane Faroult [sfaroult@xxxxxxxxxxxx]
Sent: Friday, May 13, 2011 12:35 AM
To: robertgfreeman@xxxxxxxxx
Cc: oracledbaquestions@xxxxxxxxx; ORACLE-L
Subject: Re: company database architect that doesn't like rdbms?

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>
--
http://www.freelists.org/webpage/oracle-l

Other related posts: