Introducción
Mapeo objeto-relacional, especificación frente a implementación y la trampa de las N+1 consultas.
Introducción a JPA y Hibernate
Una base de datos relacional razona en filas, columnas y claves foráneas. Un programa Java razona en objetos, referencias y herencia. Estos dos modelos no se superponen: una referencia Java es un puntero en memoria, una clave foránea es un valor copiado; un objeto Java puede heredar, una tabla no. Esta brecha tiene nombre, object-relational impedance mismatch, y todo el trabajo que hacías a mano con JDBC —copiar columnas en campos, recuperar un objeto ya cargado para no duplicarlo, decidir cuándo escribir— consiste en salvarla.
JPA es la respuesta normalizada de la plataforma Jakarta EE a este problema. Hibernate es su implementación más extendida y, con diferencia, la más antigua: Hibernate existía antes que JPA, y JPA se diseñó en gran parte a partir de él. El resultado, para ti, es un ORM que te permite escribir commande.getClient().getNom() en lugar de una unión (join), y que decide por sí solo cuándo sale el UPDATE hacia PostgreSQL.
Precisamente esa delegación es lo que hace difícil el tema. Un ORM no suprime el SQL, lo produce en tu lugar. El día en que una página que mostraba cincuenta pedidos emite cincuenta y una consultas en lugar de dos, el problema no está en tu código: está en una decisión que Hibernate ha tomado a partir de anotaciones que escribiste sin medir su efecto. Este curso está construido en torno a ese escenario, llamado problema de las N+1 consultas. Aparece desde esta lección, se produce ante tus ojos en la lección sobre las relaciones y se resuelve de forma limpia en la lección de optimización.
Comentarios
Los comentarios funcionan con GitHub Discussions
Inicia sesión con GitHub para participar en la discusión