ORMs vs. SQL

Uno de los malentendidos que más daño ha causado al mundo de la informática es el objetivo del patrón MVC para dividir nuestro software en diferentes «capas» o componentes independientes entre sí: el modelo (la parte encargada de almacenar y actualizar los datos), la vista (el interfaz con el que interactúan los usuarios) y el controlador (donde reside la lógica de negocio a aplicar a la información del modelo en base a los inputs recibidos de la vista). Aplicando el MVC, por ejemplo, conseguimos que con un único modelo y lógica de negocio podamos dar servicio a diferentes vistas -por ejemplo, una aplicación móvil o una página web- y, también, que nuestra lógica siga siendo válida independientemente de si la información se guarda en una base de datos u otra, en memoria o en ficheros, abstrayéndonos de la gestión a bajo nivel del modelo.

Pero una cosa es abstraerse del modelo de datos y otra muy diferente ignorarlo por completo, que es lo que desgraciadamente ocurre en demasiadas ocasiones. Una cosa es que la calefacción de gas natural de tu vivienda funcione independientemente de que el suministro provenga de Naturgy o Endesa; y otra, muy diferente, que pretendas cambiar tus radiadores por hilo radiante eléctrico. Ante cambios de semejante calado, la estructura de tu casa -y de tu software- se va a tener que adaptar.

Esa confusión entre abstracción y completa ignorancia ha calado en profesionales, empresas y distintas instituciones de enseñanza, llevando al mercado una generación entera de desarrolladores que no solo no entienden cómo funciona una base de datos sino que apenas saben cómo trabajar con ella. Frontenders -especialistas en desarrollar la vista- a los que se les infantiliza, excluyéndolos del diseño del modelo porque se supone que nunca trabajarán con él directamente, la misma memez que no contar con la opinión de electricistas a la hora de diseñar la estructura de un edificio porque cuando instalen un punto de luz no afectará a la misma. Y backenders -supuestos especialistas en desarrollar el controlador y el modelo- que no manejan conceptos como pool de conexiones o transacciones ACID y no dominan SQL, el lenguaje de consulta estándar en bases de datos relacionales, más allá del «SELECT * FROM» más básico.

Ese desconocimiento ha hecho que muchos de esos desarrolladores usen una herramienta como los ORMs, perfectamente válida para gestionar tediosas tareas, como auténticas llaves inglesas de código a los que les delegan toda interacción con el modelo e incluso, la generación misma del esquema de la base de datos.

Esa mala práctica, condicionar el modelo en base al código en vez de diseñar el segundo a partir del primero, pervierte el espíritu mismo de nuestra profesión -la Informática- que es la disciplina encargada de gestionar la información de la forma más eficiente posible para cada circunstancia. Esa es nuestra verdadera misión, el software, el hardware y las infraestructuras -desde un satélite a un cable submarino intercontinental- son solo las herramientas que usamos para lograrlo.

Pero, sobre todo, en mi opinión revela una concepción profundamente equivocada sobre cómo debe diseñarse una solución informática. Como desarrolladores, nuestro objetivo principal es construir una solución para un problema determinado, no programar. Y, para conseguirlo, debemos definir un modelo de datos -un conjunto de variables, relevantes para dicha solución, extraídas de la realidad- a partir del cual diseñaremos software que funcionará de una manera o de otra -la lógica de negocio- dependiendo de los valores contenidos en el mismo, no al revés. Podemos crear ese modelo directamente en la herramienta donde gestionaremos nuestra información o abstraernos de la misma y diseñarlo con código, usando el modelado orientado a objetos y técnicas como el DDD, pero sin perder nunca la perspectiva de que el uso de una herramienta (el ORM) jamás debería condicionar nuestra solución. Los ORMs no gestionan bien el mapeo entre base de datos y código, así que delegarles la creación del modelo no parece una buena idea. 

Esa perversión en el empleo de los ORMs, ha provocado un enfrentamiento abierto y despiadado entre sus partidarios y sus detractores, que trasciende la eficacia de los mismos para llegar hasta la concepción misma de nuestra profesión.

Pero, a pesar de las opiniones extremistas, tanto el uso de ORMs como de SQL tiene ventajas e inconvenientes que debemos ponderar con pragmatismo, dependiendo de nuestras necesidades y recursos.

DRY: para resolver simples CRUDs (creación, actualización y borrado de datos, sin mucha más lógica) puede tener todo el sentido del mundo usar un ORM en vez de repetir código que, básicamente, hace lo mismo una y otra vez.

Rendimiento: no tiene sentido traerte media base de datos para sumar 3 números. Creando tu propio SQL siempre puedes optimizar las consultas, por ejemplo, al generar informes complejos que tiran de varias entidades.

Tolerancia al fallo: la posibilidad de cometer un error de nomenclatura o sintaxis que no detecte el editor siempre es infinitamente mayor al trabajar directamente con SQL.

Barrera de Entrada: los dos puntos anteriores no suelen ser problema para un desarrollador con experiencia con SQL, pero si no se conoce el lenguaje ni la lógica relacional, es cierto que implica una barrera de entrada que es mucho menor en el caso del ORM.

Confort de desarrollo: mientras es posible depurar la ejecución de un ORM, con el SQL -que es un lenguaje declarativo- es mucho más complicado. Algunos motores permiten depurar procedimientos almacenados, pero pocos ofrecen una API que permita integrar esa depuración en el entorno de desarrollo.

Seguridad: se supone que un ORM tiene resueltos todos los potenciales problemas de seguridad que implica hacer consultas directas a la base de datos con parámetros recogidos de la capa cliente como, por ejemplo, SQL Injection. Se supone. En cualquier caso, nada que no podamos resolver vía código, siguiendo buenas prácticas.

Portabilidad: una de las principales ventajas de los ORMs es que supuestamente funcionan con casi cualquier base de datos relacional, así que si cambias de base de datos (una decisión que no se suele tomar a la ligera) las modificaciones que tendrás que hacer en tu código serán mínimas. Pero si tienes la disciplina de usar solo SQL ANSI (el estándar, sin extensiones propietarias de un producto determinado) tampoco tendrías que tener demasiados problemas.

Como cualquier tecnología, ni el SQL ni los ORMs son malos o buenos de forma intrínseca, depende de nosotros usarlos de forma apropiada. Tiene tanto sentido utilizar ORMs para evitar la repetición de consultas sencillas a base de datos, como el empleo de SQL en consultas complejas con múltiples parámetros de búsqueda o la generación de reportes con agregados de información de varias entidades. Eso sí, siempre debería ser nuestro código el que se adapte al modelo, no al revés.

La posibilidad de usar ORMs debería recordárnoslo constantemente porque, paradójicamente, la probabilidad de que el valor que aporte nuestro software dependa más del volumen y calidad de la información con la que interactúe, en vez de la lógica de negocio que aplique sobre la misma, es inversamente proporcional a la cantidad de sentencias SQL personalizadas que contenga.

Y aunque con el estado del arte actual es perfectamente factible ganarse la vida desarrollando software comercial sin tener ni idea de bases de datos y parecen existir ciertos intereses creados para persuadirnos de que es un conocimiento inútil -para convencernos de que somos backenders, frontenders o loqueseaenders, en vez de simplemente desarrolladores-  si de verdad queremos comprender cómo funcionan las aplicaciones que construimos más allá de la majia, si no queremos ser un simple engranaje más en el ciclo de desarrollo, deberíamos conocer cómo se gestiona la información que con la que trabaja nuestro software. Da igual en qué trabajemos, lo que importa es lo que somos. Y lo que queremos ser.

Programar una aplicación sin tener ni idea de las características de la base de datos en la que se sustentará es como diseñar un Fórmula 1 sin tener en cuenta el motor que llevará. Nadie espera que lo fabriques tú mismo, ni que conozcas al dedillo todas las piezas que lo componen, pero al menos sí cómo funciona.

Este texto se publicó originalmente en la Bonilista, la lista de correo de noticias tecnológicas relevantes para personas importantes. Si desea suscribirse y leerlo antes que nadie, puede hacerlo aquí ¡es bastante gratis!

---

---

---