[sf-perl] ORM vs. DBI
friedman at highwire.stanford.edu
Sun Feb 27 10:44:10 PST 2011
Aha. Yeah, I was thinking about how using an ORM for a small database would be useful. You could design the data objects in Perl and then run a script to actually create the db from that. No more accessor writing too. (Although that's easily taken care of in other ways.)
It was surprising to me how much of the DBIx::Class documentation was about "How do I get this funky SQL to work with DBIC?" Thinking about it in terms of reinventing the wheel makes that make more sense. You wouldn't want to write an ORM that handled 100% of what 100% of the people needed -- that'd be huge and overkill for 90% of users. Instead you cover the basics and let people use the same db connections with other methods to do the complex stuff.
PS - There's no way I'm converting this 1400+ module system to use an ORM now. That'd be crazy. (Although I can see the benefits for job security...) I was looking at a side project which has the chance to "start over" with something simpler.
Mike Friedman | HighWire Press, Stanford Univ | friedman at highwire.stanford.edu
On Feb 27, 2011, at 9:56 AM, yary wrote:
> I've written/been in multi-hundred-table enterprise apps- which used
> SQL/DBI, and then had a brief stint working on a couple web apps that
> had maybe a dozen tables- and used an ORM. For that the ORM made
> coding quicker- typing "select this from here, there where
> here.key=there.key and that=foo" gets monotonous after a while. ORMs
> are good for the common simple operations.
> I always ended up having to write SQL to do things the ORMs weren't
> written to do- and that's fine. Any ORM that had the expressive power
> of full SQL is re-inventing the wheel!
> There's no need to convert any existing database app to an ORM, if
> you're starting from scratch then using an ORM will save you writing
> some convenience classes.
> SanFrancisco-pm mailing list
> SanFrancisco-pm at pm.org
More information about the SanFrancisco-pm