Spring GDS 25 Aniversario
Una empresa de logística que envía a 190 países construyó algo para enviarse a sí misma.
El mapeo objeto-relacional es una capa que te permite trabajar con una base de datos relacional a través de los objetos de tu lenguaje de programación en lugar de SQL puro. Una fila de una tabla de usuarios se convierte en un objeto User. Leer, crear y actualizar registros ocurre mediante llamadas a métodos, y el ORM genera el SQL por debajo. Las columnas de la base de datos se mapean a campos del objeto, y las relaciones a referencias entre objetos.
La idea es mantener al desarrollador en un único modelo mental. Piensas en objetos y relaciones, no en joins ni alias de tablas, y el ORM también se ocupa de detalles tediosos y propensos a error, como escapar las entradas para prevenir inyección SQL. La contrapartida es una capa de abstracción que puede ocultar lo que la base de datos hace en realidad. La trampa clásica es el problema de las N+1 consultas, donde cargar una lista y luego tocar las relaciones de cada elemento dispara cientos de pequeñas consultas en vez de un solo join eficiente. Un equipo que lista 50 entradas de blog con sus autores puede provocar sin querer 51 consultas a través de un ORM, cuando un único join habría bastado, salvo que le indiquen al ORM que cargue la relación de forma anticipada.
Prisma, TypeORM, Drizzle, Sequelize, Hibernate y el ORM de Django son ejemplos habituales. La mayoría permite bajar a SQL puro para las consultas que la abstracción resuelve mal.
Usamos un ORM para el grueso del acceso a datos de una aplicación, porque hace que los casos comunes sean rápidos de escribir, seguros frente a inyección y fáciles de leer meses después. Donde de verdad aporta es en el noventa por ciento de las consultas, las sencillas. La disciplina está en saber que existe el otro diez por ciento y no fingir que la base de datos ha desaparecido solo porque haya un objeto ordenado delante.
Por eso vigilamos las consultas que un ORM genera de verdad, sobre todo los patrones N+1 que parecen inofensivos en el código y aplastan una base de datos bajo carga real. Para los informes pesados y las agregaciones complejas en las que un ORM pelea contra el problema, bajamos a SQL escrito a mano y lo mantenemos legible. Ese equilibrio entre productividad y control recorre nuestro desarrollo de aplicaciones web a medida y nuestro desarrollo web, donde la capa de datos decide en silencio si un producto sigue siendo rápido a medida que crece.
¿La aplicación se ralentiza a medida que crecen tus datos? La capa de consultas suele ser la culpable. Echémosle un vistazo.
Una empresa de logística que envía a 190 países construyó algo para enviarse a sí misma.
Convertir una marca en un negocio que funciona.
Medio millón de personas. Una app. Cero caos.















