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

I'm not the best DBA in the world by a long shot, but I'm not bad, and I was (and still am) a developer, so I speak from both sides of the fence.

>> ....These folks should try to use the software that is
>> already out there instead of re-inventing the wheel for
>> every project they get involved in."

Agree, 100%.

>> This quote was more directed at the j2ee
Agree 100%. In fact anyone thinking of using Java - in my opinion - should be kept well away from any database!

>> crowd that wants to
>> ignore the use of FK's and other constraints, but I think it
>> applies here.

Please, don't start me off on this subject. I have lost count of the number of "discussions" I've had with various vendors and developers who think that the application is the only place in the entire multi-verse that will access the data in the database. They simply don't "get it" that the data is the most important thing, not their application which may evolve and will go extinct long before the data is no longer required.

I usually find - by cunning use of a quick SQL statement to update a table - that the application is written this way in order to assume that the data it reads from the database will be consistent with what the application wrote into the database. I've broken numerous applications simply by setting a column to a "this shouldn't happen" value and seeing what happens. Hugely enjoyable! ;-)

Management sometimes don't help either. A system I inherited a number of years back required "create any procedure" and "execute any procedure" to work "properly". I demonstrated to a manager that this was a huge security hole by creating SYSTEM.DROP_USER procedure and when executed, dropped the entire application schema, all the data and everything. His response? Don't tell the customers about this. Sigh.

<SNIP>

>> Besides being expensive,
>> custom made solutions are often built to deal with custom
>> made problems.

And say what you like about Oracle Support, but with these home brewed systems, what do you do for support when the chief "architect" and his/her followers decide to leave the company?

>> The problem I see with developers is not that they run their
>> mouths off, but that they don't ask questions, and don't
>> bother to understand the product they are using (the same
>> might be said about some DBA's too).

I agree again. On both counts. We have, at present, a set of standards that we supply to all our developers and to any vendor wishing to write for us. Rules 1 and two are, slightly paraphrased:

1. Know your database. Know how it works, what features it gives you and how use them. We have paid an expensive license to use these features so your application should use them where appropriate.
2. Know your development tool. Know its features and what it allows you to do. Make good use of it.

Actually, rules three & four are good as well:

3. Instrument your code. You will appreciate it when a bug arises and you have information to help track it down quickly.

4. There is no such thing as a "database agnostic" system. Code for Oracle won't work on DB2. Anything written in this manner must be using the minimum level of features common across all potential databases - see rule 1 above re licensing costs and features!

>> They want to say "it should work this way", "it should be able to do
>> this", or better yet, "I don't trust the database to do
>> what I want."

Welcome to my world! And, I have noticed, it's always the Java developers who re-invent the wheel. What is it that makes them do this? I have a feeling that they just want to "show off" their "skills" in writing lots and lots of Java code. Don't they know that the database server is running oodles more power than their middle tier server and can do the work faster, better and cheaper (in power terms) than anything that their pseudo-compiled code can do?

That was a hypothetical question by the way, they usually don't know!

I once argued about Java performance with a very good Java developer. My point was that performance basically sucked - compare the old Oracle 8.0 installer written in compiled C with the new Java installer. He said that he had implemented a system, in Java, that handled 5,000 transactions an hour (Fast eh?) and that performance was excellent. Then, he admitted, that to get it up to that "speed" they had to assume that no errors would occur and took all the error checking code out!

More recently, in a place I worked, a system was created in Java to replace an old creaking system. It was predicted that it would execute 40,000 transactions per hour. Then 30,000, then 20,000, then 10,000 then they stopped predicting and went very quiet. It finally went in to production and ran alongside the old system for about three years. They never did switch off the old system, and now, the old system is still running while the "new improved" replacement has been decommissioned. A complete waste of time, effort and money.

My point being that the old system took advantage of the features of the database and used them to good effect. The new system didn't and simply treated the database as a "bit-bucket".

>> 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

I thoroughly recommend Stephane Faroult and Pascal L'Hermite's excellent book on refactoring - Refactoring SQL Applications, available from all good amazon.co.uk shops here
http://www.amazon.co.uk/Refactoring-SQL-Applications-Stephane-Faroult/dp /0596514972/ref=sr_1_17?s=books&ie=UTF8&qid=1305270242&sr=1-17 (hope the link doesn't wrap!). I think thatif you replace ".co.uk" with ".com" in the above URL, it will work fine. That's what I normally do (the other way around) when someone posts an amazon.com URL.

>> and have the gaul to wonder, why is the database so slow.
Because there are *never* any problems with developer code, the problems are *always* with the database. This is what we DBAs have to deal with frequently - it's not working, it *must* be the database. I usually reply - give me the evidence. There is none. I supply them with a 10046 trace at level 12 (just to be mean!) and prove that the application is broken. Not many developers can actually read and interpret a 10046 trace, regardless of my best efforts to teach them (I could be a bad teacher of course!).

Also, getting back to the features of the database, we have tkprof (although I use other tools, my favourite being the perl script from Norbert Debes excellent book Secrets of the Oracle Database - http://www.amazon.co.uk/Secrets-Oracle-Database-Experts-Voice/dp/1430219 521/ref=sr_1_1?ie=UTF8&s=books&qid=1305270500&sr=1-1 (also available on Kindle) which basically does a "Method R" on the trace file.

Ever heard of a developer using DBMS_PROFILER?

>> Sigh..... I love developers, I really do..... but they need
>> to be taught..... they need to learn.
But they need to listen and understand as well. This is what I find is wrong, programming "flavour of the month" paradigms come and go, why bother to deeply learn and understand something when you know it will be replaced "very soon now" by something new - like "VB.NET on Rails" or similar!

(Ok I was kidding about VB.NET on Rails!)

>> 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 evangelists, we have
>> not sold our wares, or taught the lessons that need to be taught.
I disagree. I'm getting to the stage of living through "Groundhog Day" explaining to people why a referential integrity constraint is a good thing as opposed to having the application check it for me and so on. They seem to have, in most cases, a mental block or a downright smugness that makes them think that a DBA doesn't know anything about programming applications.

In a past life I wrote code and every Monday we had a team meeting to go through someone's work of the last week. All the developers had a say in what was "wrong" what could have been done to improve it and so on. Any deviation from standards was jumped on and so forth. Peer review in other words. I don't know of any institution where that takes place anymore - there may be some - but nowadays it's all just write it and bung it into production if it looks like it runs ok. Also, people nowadays get very possessive about their code, thou shalt not criticise lest the wrath of a disgruntled developer befall you.

And, as for so called vendors, I still get instructions to :

create user app_owner identified by app_owner ...; grant connect resource dba to app_owner; grant create session to app_owner;

And then, the application and everyone using it logs in as app_owner. Did I mention that the password is hard coded into the application? Do they realise exactly what they are doing? How about connect & resource being changed between Oracle versions and not meaning the same as they did back in the good old days of 8i and 9i?

I despair, and also refuse to allow any such rubbish near my (yes, my!) databases.

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

I think, in many cases, that we have been good stewards and teachers. And in many cases, we have been completely wasting our time. :-(

"Those who can, do. Those who can't write Java code." ;-)

<Dons flame proof suit and prepares for the backlash from Java people.>

Cheers,
Norm.

PS. Usual rules apply, the above are purely my opinions, observations and facts. They are not necessarily those of my employer (at the moment!) whose disclaimer will be almost as long as my eRant above. Also, other opinions are available - but mostly, they will be wrong! ;-)

Information in this message may be confidential and may be legally privileged. If you have received this message by mistake, please notify the sender immediately, delete it and do not copy it to anyone else.

We have checked this email and its attachments for viruses. But you should still check any attachment before opening it. We may have to make this message and any reply to it public if asked to under the Freedom of Information Act, Data Protection Act or for litigation. Email messages and attachments sent to or from any Environment Agency address may also be accessed by someone other than the sender or recipient, for business purposes.

If we have sent you information and you wish to use it please read our terms and conditions which you can get by calling us on 08708 506 506. Find out more about the Environment Agency at www.environment-agency.gov.uk

--
http://www.freelists.org/webpage/oracle-l