Os presentamos una pequeña introducción teórica a ORM: Object-Relational Mapping (o Mapeo Objeto-Relacional) en la cual se muestran tanto ventajas como desventajas de esta metodología de programación y como emplearla en vuestros proyectos PHP.

Autor: Iván Guardado

¡Mi hobbie es la programación! Llevo unos cuantos años dedicándome al desarrollo de software y últimamente especializándome en web. Actualmente trabajo en Cokidoo, de la cual soy cofundador. Si queréis podéis seguirme por twitter.

¿Qué es ORM?

Es una técnica de programación que nos permite vincular los objetos usados en nuestro modelo de la aplicación con una base de datos relacional.

El principal problema surge porque hoy en día, prácticamente todas las aplicaciones están diseñadas para usar la Orientación a Objetos (POO), mientras que las bases de datos más extendidas son del tipo relacional.

La mayoría de aplicaciones están diseñadas orientadas a objetos, por contra los sistemas de bases de datos más extendidos son del tipo relacional.

Las bases de datos relacionales solo permiten guardar tipos de datos primitvos (enteros, cadenas de texto,etc…) por lo que no se puede guardar de forma directa los objetos de la aplicación en las tablas, sino que estos se deben de convertir antes en registros, que por lo general afectan a varias tablas. En el momento de volver a recuperar los datos, hay que hacer el proceso contrario, se deben convertir los registros en objetos.

Es entonces cuando ORM cobra importancia, ya que se encarga de forma automática de convertir los objetos en registros y viceversa, simulando así tener una base de datos orientada a objetos.

¿Por qué usar ORM?

Actualmente existen numerosos sistemas o librerías para incluír en proyectos desarrollados bajo cualquier lenguaje de programación y que en ámbitos generales nos aportan las siguientes ventajas…

Rapidez de desarrollo

La mayoría de las herramientas ORM disponibles, permiten la creación del modelo a través del esquema de la base de datos, es decir, tu creas la base de datos y la herramienta automáticamente lee el esquema de tablas y relaciones y crea un modelo ajustado.

Esto quita mucho tiempo de “coding” repetitivo y que, seguro, el sistema hace mejor que nosotros, ya que los humanos siempre podemos cometemos fallos tontos :) .

Por otro lado, una vez que se tiene el modelo creado, el programador irá mucho más rápido gracias a la metodología totalmente orientada a objetos, olvidándose así de las consultas a la base de datos.

Abstracción del motor de base de datos

Todo sistema ORM que se precie debe de generar de forma automática las consultas a la base de datos para convertir los registros en objetos (y viceversa) y éstas deben poder adaptarse a los distintos proveedores (MySql, Oracle, PostreSQL,etc…).

Esto permitirá a los desarrolladores tener una preocupación menos a la hora de comenzar un proyecto, ya que tienen la seguridad de que un cambio drástico en el proveedor de base de datos, no impactará para nada en el tiempo de vida del proyecto.

Lenguaje propio para consultas a la base de datos

Otra característica importante (de hecho seguramente la que más) es la exposición de clases y métodos que nos dan las herramientas ORM para poder extraer los datos de la forma que necesitemos (filtros, ordenaciones, agrupaciones).

Aquí es en donde los desarrolladores de la herramienta tienen que poner toda la carne en el asador, permitiendo a la gente olvidarse de la sintaxis Standard Query Language (SQL) para usar el propio lenguaje de la herramienta.

A continuación unos ejemplos de distintos sistemas ORM:

Linq

Northwind db = new Northwind(connectionString);
// Se usa la palabra reservada 'var' porque no hay nombre para el tipo resultante de la proyección
var q = from o in db.Orders, c in db.Customers
where o.Quality == "200" && (o.CustomerID == c.CustomerID)
select new { o.DueDate, c.CompanyName, c.ItemID, c.ItemName };

Hibernate

 //Query using Hibernate Query Language
String SQL_QUERY =" from Insurance as insurance where insurance.lngInsuranceId='1'";
Query query = session.createQuery(SQL_QUERY);

Desventajas de ORM

Como no va a ser todo cosas bonitas, enumero a continuación algunos puntos negativos a la hora de incluír ORM en tu proyecto:

  • Curva de aprendizaje: Las herramientas (o librerías) ORM suelen ser muy amplias, por lo que llegar a explotar su máximo rendimiento costará tiempo. Antes de incluír esta tecnología en tu proyecto, estudia y haz pruebas, sobre todo si el proyecto es entre mediano y grande. Si te metes en un proyecto con algo de complejidad sin conocer a fondo el sistema ORM, seguramente te estés metiendo en un problema.
  • Menor rendimiento: Está claro que tener una capa tan enorme entre tu código y el sistema de base de datos, ralentizará un poco la aplicación. Pongamos el ejemplo para una simple query, el sistema tendrá que: convertir la consulta al SQL del proveedor usado; enviar la consulta; leer registros, limpiarlos y convertirlos a objetos. Depende del encargado de proyecto decidir si este descenso en performance se verá compensado con la facilidad y velocidad de desarrollo.
  • Sistemas complejos: Normalmente la utilidad de ORM desciende con la mayor complejidad del sistema relacional. Es decir, si tienes una base de datos compleja, ORM también se te hará más complejo y perderás más tiempo adaptando tus clases que en un sistema de menor complejidad.

ORM en PHP

A continuación os pongo un listado de liberías ORM para incluír en tus proyectos PHP:

  • Doctrine: un framework que a pesar de ser joven, es muy completo. Una de sus características más importantes es la posibilidad de acceder a la base de datos a través de un lenguaje integrado llamado Doctrine Query Language (DQL). Tiene una documentación muy completa y sólo es compatible con PHP 5.
  • Propel: uno de los más antigüos y respaldados con frameworks como symfony. Tiene muy buena documentación y sólo es compatible con PHP 5
  • ADOdb Active Record: basado en la muy conocida librería de abstracción ADOdb. Funciona con PHP 4 y 5.

Si bien existen más sistemas, estos son los más utilizados actualmente.

Conclusión

Si todavía no estás usando ORM en tus proyectos, ya es hora de que te pongas las pilas :) .

No tengas miedo y creas que todo esto te complicará las consultas o que no vas a poder hacer ciertas cosas porque te limita, más bien es todo lo contrario. Decídeite por alguno de los frameworks citados, estúdialos y verás como es más fácil de lo que parece.

Espero que os haya gustado, nos vemos en el próximo artículo. ¡Un saludo!

¿Necesitas desarrollar un proyecto web o para móviles? ¡Estamos disponibles!

Visitar Cokidoo

Cokidoo, los creadores de Ontuts, desarrollamos proyectos tecnológicos centrados en redes sociales y aplicaciones web, aplicaciones móviles y consultoría web y bases de datos.

Somos jóvenes, inquietos, versátiles, apasionados por la innovación y enfocados en las nuevas tecnologías. Con Ontuts tratamos de compartir nuestro conocimiento adquirido en los distintos proyectos, ayudando a la comunidad y mostrando nuestra capacidad tecnológica.

Si necesitas un presupuesto sin compromiso, estamos disponibles, no dudes en contactar con nosotros.

Comentarios en esta publicación (9 comentarios)

¿Te ha gustado esta publicación? ¡Puedes compartir tu opinión con todos nosotros! Simplemente pincha aquí mismo.

Hace muy poco buscaba info sobre esto, de todas es un tema del que “cada maestrillo tiene su librillo”, casi nadie lo hace igual…

creo que el costo beneficio es muy grande y la calidad final se ve opacada, tal vez tendremos calidad y rapidez en el desarrollo, pero al cliente final lo que le importa es la velocidad de su aplicación, herramientas y técnicas de este tipo nos abstrae un tanto del motor de BD, pero si que le exige mucho a el y al sistema mismo, ya que algunas tal vez solo te interesa un campo de una celda, la herramienta obviamente creara todo un objeto cuando solo necesitas un dato, y asì muchos contra que le veo, desde el casi ataque masivo desde la herramienta al motor de BD, pero eso si que bonito queda codificado :D , aunque aveces la sentencias se complican un poco cuando se requieren de combinar muchas tablas.

Clothier

Exactamente esto mismo me lo planteé yo hace unos años. Una capa superior al SQL más cercana al usuario que permitiera montar consultas SQL de una forma muy dinámica. Y, como no, todo está inventado xD. Pero leyendo este tutorial y también lo que dice Wikipedia sobre los ORM llego a la misma conclusión que llegué cuando estuve a punto de lanzar a programar algo parecido: El mundo es demasiado complejo Y DEMASIADO DINAMICO para simplificarlo.

Me explico. Para tablas con enlaces simples y una sólida estructura referencial de proyecto académico, ok, aceptamos barco. Pero cuando tienes delante un proyecto vivo donde el cliente te pide nuevas funcionalidades continuamente y donde, por lo general, acabo uno defecándose en la base de datos: el ORM no sirve para nada.

Creo que esto cuajará cuando el SQL tradicional sea sustituido por las bases de datos orientadas a objetos. Sin embargo, hablamos de algo que todavía no está maduro. Es acojonante como el SQL lleva más de 40 años vivito y coleando y siendo usado en el 95% de los proyectos. En fin, tiempo al tiempo xD

P.D.: Gran página y grandes tutoriales. Se echa de menos una mayor frecuencia en la aparición de artículos y tutoriales.

Jorge Leguia

Me gustó el articulo. Se ve interesante aprender un ORM antes de aprender un Framework PHP mas robusto como Zend o Symfony.

Además algunas Software Factories en América Latina utilizan frameworks creados por ellos mismos a base de Smarty, Doctrine, jQuery y emplean mucho el patrón MVC.

Con respecto a las nuevas versiones del Doctrine(2.0), solo son compatibles con PHP 5.3 + .
A su vez esta versión del PHP 5.3.+ trae problemas con el PEAR (al descargar los paquetes)

Sería posible si puedes colgar un ejemplito utilizando Doctrine 2.0 y la configuración basica de un proyecto.

Saludos :)

Hola Jorge,

Queda anotada tu idea de ejemplo con Doctrine 2 :)

Gracias por tus comentarios!

franco

Un gran aporte, gracias sigue adelante

carloa aguirre

Hola hay algo q me confunde que diferencia hay entre ORM y ActiveRecord

Active Record es un patrón de desarrollo. Un ORM es una libreria o código que puede implementar o no dicho patrón.

Añade Tu Comentario