[sf-perl] ORM vs. DBI

[Michael Friedman]

Quinn,

I remember reading those slides the first time, but not quite understanding them. They make much more sense now that I know a bit about ORMs. Thanks for reminding me of them!

I agree, I had immediate worries about the one-at-a-time-ness of ORMs. Heck, I have enough trouble with my peers at the office being naive about DBs and killing the server by trying to do something one-at-a-time for hundreds of thousands of rows. The DBA would kill me if I made the code any more conducive to such things.

Still, for smaller databases or smaller data sets, I can see why the ORM would encourage faster development, especially in a shop without a trained DBA. It stops you from making the most stupid decisions (and typos), even if it doesn't handle large-scale operations. (How many times have we all forgotten the WHERE clause on an update? Hrm?)

-- Mike
______________________________________________________________________________
Mike Friedman | HighWire Press, Stanford Univ | friedman at highwire.stanford.edu

On Feb 27, 2011, at 12:10 PM, Quinn Weaver wrote:

> I agree with the points made so far about the complementary (and optional)
> nature of ORMs.
> 
> I have a talk about using Catalyst, specifically, without an ORM, which you
> may find useful. It's quite easy to make raw SQL queries in a Catalyst app and
> never worry about an ORM. Even if that's not your intention, you may glean
> some new information from its criticism of ORMs. The slides are at
> http://bit.ly/NoORM They start out with motivation, then move into
> implementation.
> 
> Do take with a grain of salt the section that criticizes the shortcomings of
> ORMs; most of those criticisms don't apply to DBIC, which is an extremely
> well-written ORM (it even supports aggregates—though you could argue that
> that's a "reinventing SQL" feature).
> 
> In general, my strongest criticism of ORMs is that they make you think about
> DBs the wrong way. They encourage a one-at-a-time mentality for DB operations:
> e.g. in a Perl foreach/for loop, open a transaction, do an update or insert
> (save), and close the transaction, *for each of hundreds or thousands of
> items*. My colleague at pgexperts.com Christophe Pettus calls this
> "pathological iteration." It really is a performance killer.
> 
> You don't have to do things this way, but the API of ORMs, combined with the
> way they isolate you from SQL, combined with (sad to say) the naive SQL skills
> of many web programmers, make mistakes natural. If you are more familiar with
> relational model, you won't fall into this trap, but you may still have
> difficulty expressing what you want to say.
> 
> The good news, though, is that you don't have to use an ORM at all. Even if
> you use one, you can still fall back to raw SQL when you need it. My talk
> doesn't cover that, but it sounds as if you have a good handle on it.
> 
> Anyway, those are my (immediate) thoughts on the subject. I hope they're
> helpful. Good luck with your project!
> 
> --
> Quinn Weaver
> PostgreSQL Experts, Inc.
> http://pgexperts.com/
> 1-888-743-9778 (my extension: 510)
> 
> 
> 
> 
> _______________________________________________
> SanFrancisco-pm mailing list
> SanFrancisco-pm at pm.org
> http://mail.pm.org/mailman/listinfo/sanfrancisco-pm