|
in reply to How to structure applications using a RDBMS
To give a slightly different perspective, here's some thoughts from the DBA side of things.
Programming Pros
- It's nice from the programming point of view to have automatic code generators that do things to remove you from the SQL
- Encapsulating business logic in Perl (or whatever language takes your fancy) modules makes things nice and easy for this project
- Abstracting the SQL to a completely different module away from our nicely structured Perl keeps things looking nice and neat
DBA Cons
- Unfortunatly this kind of code generation leads to stuctures like:
my $sth1 = MYSQLMODULE::generate_result_set(TABLE => "employees",
COLUMNS => qw(name positio
+n salary id),
WHERE => "department = 'SA
+LES'");
$sth1->execute();
while (my @employee = $sth1->fetchrow_array) {
my $sth2 = MYSQLMODULE::generate_result_set(TABLE => "commission",
COLUMNS => qw(total_com
+mision),
WHERE => "id = $employe
+e[2]");
$sth2->execute();
my @commission = $sth2->fetchrow_array();
print "$employee[0]($employee[1]) = $commission[0]\n";
}
...etc...
which is highly inefficient, and should be replaced with a single SQL statement with a join.
- It doesn't matter which language you code your business logic in, in 2 years time the company will be using something else and someone will have to re-write the business logic in todays latest fad language. Best off to write it in the database's stored procedure language and let everybody, no matter what language they code their appilications in, be subject to the same, consistent, business rules. If the rules change, the code only has to be changed in one place.
- 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. A DBA having to wade through yards of code in Perl, C, C++, Java, Cobol, Fortran - on the same day! - is not a lot of fun (challenging, but not a lot of fun), to find an offending piece of SQL, and then trying to get the correct programmer to check-out, edit, test, check-in, rebuild, deploy, etc the new application whilst production is on its knees and a swarm of managers is hovering with intent is, again, not a lot of fun (stressful, but not a lot of fun). Again - encapulate the SQL in the database's stored procedures and the DBA will let you sleep in your cubicle.
I haven't adhered to these rules in the past, for instance - not using stored procedures because I want to make to application as portable as possible, but then having to make the SQL highly optimised for a particular platform to get any sort of performance, means that the application is unable to be easily ported anyway. Think of SQL the same way as everybody in PM thinks of HTML (replacing the Web Designer with the DBA, of course) - get it out of your application, so you don't have to worry about it (make it SEP). If you haven't got a DBA up to the job, just /msg me... :)
rdfield |
Re: Re: How to structure applications using a RDBMS
by adamsj (Hermit) on Jul 19, 2002 at 12:44 UTC
|
"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.)"
adamsj
They laughed at Joan of Arc, but she went right ahead and built it. --Gracie Allen | [reply] |
|
|
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 :)rdfield
| [reply] |
|
|
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.)
adamsj
They laughed at Joan of Arc, but she went right ahead and built it. --Gracie Allen | [reply]
[d/l]
[select] |
|
|
