Re: How to control developers writting better SQL

> 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 Received on Fri Oct 27 2000 - 07:56:20 CDT