Capítulo 21. Adoptar el pensamiento SQL
Este trabajo se ha traducido utilizando IA. Agradecemos tus opiniones y comentarios: translation-feedback@oreilly.com
Dean Wampler
Mira en esta consulta:
SELECT c.id, c.name, c.address, o.items FROM customers c JOIN orders o ON o.customer_id = c.id GROUP BY c.id
Adquirimos todos los clientes que tienen pedidos, incluidos sus nombres y direcciones, junto con los detalles de sus pedidos. Cuatro líneas de código. Cualquiera con un poco de experiencia en SQL, incluidos los no programadores, puede entender esta consulta.
Ahora piensa en una implementación Java. Podríamos declarar clases para Customer y Order. Recuerdo a consultores bienintencionados diciendo que también deberíamos crear clases para encapsular colecciones de ellas, en lugar de utilizar colecciones Java "desnudas". Seguimos necesitando consultar la base de datos, así que recurrimos a una herramienta de mapeo objeto-relacional (ORM) y escribimos código para ello. Cuatro líneas de código se convierten rápidamente en docenas o incluso cientos de líneas. Los pocos minutos que tardamos en escribir y refinar la consulta SQL se convierten en horas o días de edición, escritura de pruebas unitarias, revisión del código, etcétera.
¿No podemos implementar toda la solución sólo con la consulta SQL? ¿Estamos seguros de que no podemos? Incluso si realmente no podemos, ¿podemos eliminar el despilfarro ...
Become an O’Reilly member and get unlimited access to this title plus top books and audiobooks from O’Reilly and nearly 200 top publishers, thousands of courses curated by job role, 150+ live events each month,
and much more.
Read now
Unlock full access