use Perl

• A few comments (Score:4, Interesting)

  by VSarkiss (704) on 2003.04.07 20:19 (#18855) Journal

  Overall, I liked it, but I was a database/SQL guy before I was a Perl guy, so I do have some comments. Don't worry, I'm not going to be harsh. ;-)

  • Your point about not using select * and insert without a specific column list is very well taken. The problem you specify next, though, is that columns don't contain what they sound like they should. This is the same problem as mis-named variables, or abuse of globals in a Perl program. (Equally bad ideas, in other words.) However, it's not clear than any of the techniques you present later will fix this. If you're afraid of modifying the database, you may be equally afraid of modifying the class. "Let's just shove it in here" can be accomplished in any programming language, with any tool!
  • I like the use of phrasebooks, but do be aware that they're really stored procedures in a cross-platform disguise. The benefits you list (on slide 38) all accrue to stored procedures as well. Nonetheless, there are problems with them. First, knowing where to put the dividing line between the SQL and the rest of your code is something that I've found only comes with experience. I've seen many cases where a bad separation caused more headaches than it solved. And as you point out later, tests and good configuration management are key to making the technique work successfully. ("No, version 2.36 of the program needs version 3.85 of the SQL. Oh, but that needs version 16 of the data model. We're screwed.")
  • I'll be honest, I've never thought "avoid writing SQL" was a win. SQL is a non-procedural programming language that works really well for relational databases. A well-written SQL statement can be clearer and faster than a lot of the code you're showing. And as for performance, I've yet to see an OO-style database interface generator produce anything beyond trivial SQL. I realize this is similar to "assembly written by hand is always faster than compiled code", but in the case of OO databases -- as opposed to compiler technology -- I think it's still true.
  • Minor typo's: slide 14, last bullet point: "one's has" => "one has"; slide 33, last bullet: "propogate" => "propagate"

  Now, it may not be clear from the above, but I really liked it. I think you make good overall points, and these are minor points I'm raising. But they may be raised by others as well, so be ready.

  Reply to This

  • Re:A few comments (Score:2, Interesting)

    by johnseq (1046)

    A slightly different, possibly complementary approach to schema change management would be parsing the phrasebook SQL to identify the field/table name dependencies. If I change phone to home_phone, I just run my phrasebook through a SQL parser to determine effected queries, and optionally to rewrite them. I like that approach (as opposed to inlining references to a fieldname registry) because it keeps the SQL a more readable, and the adoption curve lower.