RE: company database architect that doesn't like rdbms?
- From: "Dunbar, Norman (Capgemini)" <norman.dunbar.capgemini@xxxxxxxxxxxxxxxxxxxxxxxxx>
- To: <robertgfreeman@xxxxxxxxx>, <oracledbaquestions@xxxxxxxxx>, "ORACLE-L" <oracle-l@xxxxxxxxxxxxx>
- Date: Fri, 13 May 2011 08:36:22 +0100
Morning Robert,
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
--
//www.freelists.org/webpage/oracle-l
Other related posts:
