ORMs vs. SQL

Si las expresiones regulares son la kryptonita de muchos desarrolladores, el SQL es su aceite de ricino: una herramienta que nos puede beneficiar enormemente, pero también causar un enorme daño si no se administra con precaución, y con sabor desagradable para la mayoría


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 ellaFrontenders -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.

La propuesta

Tecnofor -Platinum Partners de Atlassian y amigos de esta casa- acaba de poner patas parriba los servicios para la plataforma Jira, lanzando el awesómico Soporte Jira Basic. Este servicio de soporte profesional te permite tener la tranquilidad de que, si tu Jira se resfría, un experto te atenderá en menos 24 horas por solo 99€/mes.

Este nuevo servicio, diseñado para PYMES, permite a cualquier empresa acceder a los equipos de soporte que tradicionalmente solo han estado al alcance de las grandes compañías.

Con Soporte Jira Basic tendrás.

Un equipo de expertos Atlassian a tu disposición.

Respuesta en 24 horas en caso de incidencia.

Un «Health check» de tu Jira una vez por año, totalmente gratis.

Atención en español o inglés, en cualquier país.

La posibilidad de elegir pago mensual o anual, a tu comodidad.

Y si se te queda corto siempre puedes subir el nivel de soporte, con Soporte Jira Premium.

Si estás usando un Jira para cosas importantes de tu empresa y no has pensado a quién llamar si casca, esta es tu oportunidad. Además, tienen una super-promoción para la comunidad taruga: 3 MESES GRATIS. Usa el código 'BONIJIRA' en el formulario de su web y te aplicarán este descuentón de Aviñón.

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!

Conoce toda nuestra oferta de newsletters

Hemos creado para ti una selección de contenidos para que los recibas cómodamente en tu correo electrónico. Descubre nuestro nuevo servicio.

Votación
5 votos
Tags
Comentarios

ORMs vs. SQL