Advantages of ORM

PHP
9

I like using ORM because:

  1. It makes writing queries in a very readable and nice format and not having to worry about escaping values (this is what TomB said above)

  2. Database records are encapsulated within objects so I can extend their fields with additional virtual/dynamic fields. For example, if I have $product->price and $product->value I can add a $product->total_value field even though it doesn’t really exist in the database. I can also get the object to format the db values to something more flexible in PHP, for example, $user->date_registered can get me a timestamp or a DateTime object. And for saving data I can do the same, for example:

    $user->last_activity_date = time();
    without worrying about creating a specific db datetime storage format. Or do:

    $user->setNewPassword($password);

and have the object do the proper hashing.

However, I like ORM only for simple CRUD stuff. When I see examples of complicated criteria object building they make my head ache because pure SQL is much easier to read and create and much more powerful. I don’t feel like learning another ORM-query-like language that will mirror what SQL can do. Sure, if you want a total database independence then this is a good way to go but in most web applications I can’t imagine why I would want to change the database vendor because the specific database is often chosen to fulfil certain needs and not to be just a generic data store that can be swapped with another at will.

For example, now I’m building a web application that uses Postgresql and I’m making use of its special features like array datatypes, range datatypes, custom datatypes, indexes on functions and expressions, specialized comparison operators for ranges, geometric types and time intervals, spacial calculations provided by Postgres extensions, and so on and on - how can I reasonably expect any ORM library to get me support for all of these things and still provide me with database independence? Writing custom SQL to cover these cases defeats the purpose of ORM.

I’ve used Propel in the past and while it was nice for simple stuff it was making things complicated when non-standard queries were needed and it was also painfully slow. Also, changing database schema was a nightmare because an XML definition file had to be changed each time - yet another “language” to learn.

Therefore, I have mixed feelings regarding ORM. What I have settled for now is I’m using my own ORM that:

  • does only basic CRUD
  • easily accepts plain SQL (so I can retrieve any db records into the objects)
  • no criteria/query construction mechanisms (just write plain WHERE clause)
  • almost no configuration (only optional configuration of mapping table names to object names - in case auto-naming from table names is not sufficient)
  • all entity classes are auto-generated from the database so after changing structure it’s just one click to update the objects
  • fast

I believe good ORM is not possible (or is very complicated) because relations and objects are so different concepts that I prefer to accept this fact and not get away from SQL at all costs. I often find it important to structure SQL queries so that I can take advantage of unique database features. So it all comes down to requirements really.

2 Likes