Beefy Boxes and Bandwidth Generously Provided by pair Networks
more useful options

Re: Re: How to structure applications using a RDBMS

by adamsj (Hermit)
on Jul 19, 2002 at 12:44 UTC ( #183207=note: print w/replies, xml ) Need Help??

in reply to Re: How to structure applications using a RDBMS
in thread How to structure applications using a RDBMS

"All three of your points are well-taken," says a DBA who spends more time writing Perl than doing anything else, "but point three:

* Programmers don't necessarily understand (or even care) about performance issues on a particular RDBMS. Nor should they - it's not their problem, that's what the DBA gets paid for

is both true and not true. It's true that programmers don't always understand how the RDBMSs (we have Teradata, Oracle, RedBrick, and Sybase in production and create a lot of MS Access items for people's desktops, and our developers have to work across them) they use work internally, but they should care and should be willing to learn. (They also should listen to the DBA when they don't know, but that's another rant.)"


They laughed at Joan of Arc, but she went right ahead and built it. --Gracie Allen

  • Comment on Re: Re: How to structure applications using a RDBMS

Replies are listed 'Best First'.
Re: Re: Re: How to structure applications using a RDBMS
by rdfield (Priest) on Jul 19, 2002 at 14:37 UTC
    My point was specifically about each RDBMS' peculiarity when it comes to writing SQL for performance rather than functionality. I would expect a good programmer to have a broad knowledge of what functionality is available for each RDBMS they use on a regular basis, but I certainly wouldn't expect such a programmer to go to the lengths of understanding how each RDBMS optimises their SQL. For instance, I don't know DB2 at all, but I have it on very good authority that its optimizer changes with every release - keeping track of such things is surely not a job for a programmer. For another instance, a few years ago I was was called in to a large company to fix the problems that they were having with their Telephone Banking system - their daily batch update was taking 27 hours! (do the maths :) A couple of small tweaks later (changed an 'or' to a 'union all' and modified the column ordering in a couple of indexes) and the batch load time was reduced to 42 minutes. The point of that little story was that the original SQL was written by Oracle Corp consultants charging GBP150p.h. - programmers who should know how the Oracle RDBMS works :)


      I don't disagree a bit with what you've said.

      On the other hand, I think a developer shouldn't have to be told more than twice that:

      SELECT DISTINCT(item) FROM a.table
      can eat up a couple hundred gig of spool without blinking, but that
      SELECT item FROM a.table GROUP BY item
      goes by in the blink of an eye. You'd think that wouldn't be a major paradigm shift for them--but it is (okay, in one case I've been dwelling on lately). And it'd be even nicer to be heard the first time.

      (This is an oversimplified example--the point being DISTINCT versus GROUP BY.)


      They laughed at Joan of Arc, but she went right ahead and built it. --Gracie Allen

Log In?

What's my password?
Create A New User
Node Status?
node history
Node Type: note [id://183207]
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others taking refuge in the Monastery: (5)
As of 2019-10-19 21:59 GMT
Find Nodes?
    Voting Booth?