Re: How to control developers writting better SQL

Well,
  Our discussion is coming to an end but let me point out that the attitude of a person is the most utmost importance for me. He may know little he may know a lot and in the end he should realize he's gonna run out of its depth at one time or another. The problem with the current market is that the DBAs are given a god-like status which in turn gives them an ego-boost. This certainly doesnot help me and my likes who are finding systems that are thrashed and trying to explain a DBA that he has done wrong. The other problem is of course the DBA's afraid I would find something that he should have done and that he would be criticized. Anyhow those are my problems.   As for fridge and mom, my mom(dba) doesnot buy a fridge(database). I buy the fridge then the mom :) No offense mom ...

In article <39F97B74.37B8CBEF_at_edcmail.cr.usgs.gov>,   Brian Peasland <peasland_at_edcmail.cr.usgs.gov> wrote:
> > Well the true intention of the author is not always in the clear out
> > except in the aithor's mind. What better group then to criticize
 DBAs
> > then this one ? If you are checking the statements then you are the
> > second real life dba though I havenot met you.
>
> There is no better group to criticize DBAs than this one. But if you
 do,
> don't ask to be flame free. I've met a lot of DBAs who take their job
> very seriously and would feel very critical reading the same passage.
 Of
> course, I've met lots of people (DBAs or otherwise) who don't take
 their
> job seriously, but that's a digression.....
>
> > As about DBAs creating a problem, if I buy a fridge and put
 nothing
> > in it, I would expect it to work properly. In that case I wouldnot
> > expect someone to keep the fridge clean but if I have someone to
 clean
> > the fridge and the fridge gets dirty, the cleaning person tells
 me "it
> > is because of all this reckless people", I will point out to him
 that
> > it is his job to keep the fridge clean. So even if you are not
 creating
> > a problem by not adding food to the fridge, you are not really
 helping
> > either.
>
> I'll take your analogy one step further. If Mom (DBA) buys a fridge
> (database) and nothing (SQL) ever gets put into it, then the fridge
 will
> never get dirty and not need any attention. If Mom (DBA) puts
 something
> (SQL) in the fridge (db), then a good mother will make sure that the
> something is put in the fridge in the proper manner. If Dad
 (developer)
> puts something in the fridge and puts it in there properly, Mom will
 not
> have any worries. But if Dad (developer) puts something (SQL) in the
> fridge (db) without a lid and the contents spill (very bad SQL) and
> create a mess (poor performing db), why should Mom (DBA) have to clean
> up Dad's (developer) mess? Are you telling me that your Mom would put
 up
> with cleaning everyone's mess in the fridge just because she is the
> mother? I dare you to go home and tell your own mother that!
>
> It used to be, many, many years ago, that a developer took pride in
> making sure that his code did two things. One, that it worked properly
> and gave the proper results. Two, it ran as efficiently as possible.
 The
> second one was necessary since system resources were very limited. As
> resources (memory, disk, CPU speed) became plentiful, developers seem
 to
> have forgotten #2. Now it seems that a developer's only concern is
 that
> the code works properly. But with a database executing millions of
> transactions a day, #2 still needs to be taken into consideration.
>
> And it's not just the SQL code. Unless a developer gives me a copy of
> his program, I can not see everything that the developer is doing. I
 can
> only query the database and check the SQL statements. But it goes much
> further than that. I've seen developers write Pro*C code where they
> query Table A for some values. Based on those values, they query Table
> B. All of this is done in arrays with loops. But a more efficient
> solution would often be to join Table A to Table B to get the results.
> Unless I have the Pro*C code in front of me, it is very hard to tell
> what they are doing.
>
> > Here's a story where I saw one installation of an Oracle on a RAID
> > system. There is this RAID concept and there is this RAID system was
> > divided into 20 or more filesystems. Thats the DBA's understanding
 of
> > laying the files on different file systems. Another thing is of
 course
> > the sysadmin did what the DBA told him without questioning the
 merit of
> > it.
>
> It's obvious that the DBA did not understand what they were talking
> about. I was once in an Oracle ILT class. A DBA there told me that
 they
> partitioned a physical drive into multiple logical volumes so that
 they
> could balance their I/O load. I asked the DBA why he didn't just make
> multiple subdirectories off the physical drive's root directory. The
 DBA
> said that my idea would let him balance the I/O load. I just shook my
> head and walked away.
>
> There are good DBAs and bad DBAs. There are good developers and bad
> developers. There are people who think they are the greatest when they
> have no clue, no matter what job they are doing.
>
> Cheers!
> Brian
>

--
Ender Wiggin


Sent via Deja.com http://www.deja.com/
Before you buy.