[UPHPU] to ORM or to NOT
lists at kittypee.com
Mon Aug 16 11:39:05 MDT 2010
On Mon, Aug 16, 2010 at 10:55 AM, Roberto Mello <roberto.mello at gmail.com> wrote:
> On Mon, Aug 16, 2010 at 10:28 AM, Jonathan Duncan
> <jonathan at bluesunhosting.com> wrote:
>> As I see, it, the DB agnostic angle is THE angle. I have been using the CakePHP framework which has an ORM built-in. Learning to use the Cake ORM instead of straight SQL had a learning curve but since the ORM tackles so many of the tedious work that I usually had to do manually it was worth the time, to me. It really depends on what you are using the ORM for, how often you plan on using it for this project and future projects. If it is a one time deal, it may not be worth it to you.
> It certainly is THE WRONG angle for most applications, except for the
> cases where you are going to sell your app, and support for multiple
> databases is a must.
Roberto was right when talking about advanced database features and
performance. If your app is going to require advanced database
features, will not move to other database engines, and will require a
whole lot of carefully tuned SQL queries, then an ORM is definitely
*not* for you.
That said, since most projects do not require engine-specific
features, don't require carefully tuned SQL queries, and may likely
move to other engines, using an ORM can be a wonderful and extremely
I disagree with Jonathan on the point that an ORMs best point is the
database agnosticism. Database agnostic wrappers are quite easy to
achieve without any objects, relations, or mapping. IMHO an ORMs best
points are simple, effective, extremely productive coding. They
really help you get your project done very quickly.
First, I suggest you evaluate your database needs.
1. Will you need to change your database engine. eg. use SQLite for
dev, MySQL for testing, Oracle for production?
2. Do you need any advanced features? PostGIS, etc.
3. Are you going to need ultra high performance right at the start?
For the #3 you should be aware that ORMs usually offload more
processing to the application instead of the database. This can be a
good thing since scaling applications is a lot easier than scaling
databases. It can also result in more queries, though these queries
will be simpler.
The benefits of using an ORM can be:
* more efficient coding
* meeting deadlines
* easier refactoring
* simpler code
When choosing an ORM you'll want to look for several factors:
* Learning curve, will you spend more time learning it than coding (ROI)?
* Flexibility, can it work with your environment?
* Engines supported
* Hassle, does it get out the way and let you code?
* Raw Queries, does it support raw queries, just in case you need it?
More information about the UPHPU