¿Sigue siendo necesario escribir SQL?

Con tantas herramientas ORM para la mayoría de los lenguajes modernos, ¿hay algún caso de uso para escribir y ejecutar SQL en un programa, en un lenguaje / entorno que los admita? Si es así, ¿por qué?

Para mayor claridad: no estoy preguntando si los programadores necesitan saber SQL, o si debería tener una herramienta SQL en mi escritorio. Estoy preguntando específicamente por qué podría tenerlo en código (o configuración, o lo que sea) en lugar de un ORM.

• Se siente más cómodo escribiendo SQL para consultar datos que escribiendo código de procedimiento.
• Su ORM, si bien es hermoso a la vista, genera un SQL horriblemente lento en alguna área crítica.
• Debe aprovechar la funcionalidad expuesta por su RDBMS que no está / no puede estar disponible a través de su ORM.
• Cada vez que escribes SELECT * FROM..., Dios mata a un gatito. Y odias a los gatitos.
• No estás utilizando un ORM, OOP o un lenguaje moderno.

Escribir SQL complejo

ORM son excelentes para cosas básicas. Sin embargo, para situaciones complejas, tendrá que escribir SQL.

En resumen, sin duda hay una necesidad de SQL y siempre seguirá siéndolo.

• Puntos de vista
• Disparadores
• Restricciones
• Paquetes (SSIS, DTS, etc.)
• Cada vez que necesite controlar el flujo de ejecución con precisión

ORM no lo ayuda a construir, ajustar o automatizar la base de datos. Simplemente le brinda una forma alternativa de interactuar con la base de datos una vez que haya hecho todo eso.

Por supuesto:

• En general, ORM encapsula mucho, pero al final debe saber qué sucede detrás de escena. Esto es crucial para el rendimiento y la escalabilidad. Aunque dentro de la aplicación no escribo mucho SQL, pero sé más o menos cómo se ve el SQL o el DDL.
• SQL directo a menudo es bueno para escribir consultas de solo lectura. Es mucho más fácil formularlo en el lenguaje de consulta ORM y también puede limitar el conjunto de resultados (por ejemplo, 'seleccionar id de .....').
• ORM no debería mantenerte alejado de SQL en absoluto. Uso mucho SQL para consultas ad-hoc directamente en el cliente DB (como mysql-client). Le brinda una interfaz uniforme muy agradable y funcionalidades de agrupación.

Los ORM existen debido a la falta de coincidencia de impedancia entre nuestras implementaciones de bases de datos relacionales comunes y nuestras características de lenguaje OO. Son solo un puente, pero la mayoría de la gente trata el SQL como el queso Limburger en el refrigerador.

Si puede decir con razón que siempre usará su ORM u otra capa de acceso a datos abstractos en lugar de tratar SQL / procedimientos almacenados / vistas como una interfaz de primera clase, entonces probablemente estaría mejor sin tocar SQL.

En la práctica, nunca he visto un proyecto ORM puro que no requiera al menos SQL para consultar la base de datos para la validación final.

Los ORM son una herramienta en la caja de herramientas de los programadores. Tienen sus propios problemas. Algunos ejemplos son:

• No puedo controlar sql
• Sufre de n + 1 problema

Si sabe lo que está haciendo, puede usar efectivamente un ORM para reemplazar gran parte de su código de tipo CRUD. Sin embargo, no son tan efectivos para cosas complejas, son difíciles de ajustar (usted sabe que el rendimiento es una de las partes críticas del diseño de la base de datos, no emula objetos) y son francamente horribles y peligrosos en manos de alguien que no No entiendo ni escribo SQL ellos mismos.

También quiero señalar que los informes complejos no son fáciles de hacer de manera efectiva con un ORM. Y además, si no aprende el SQL simple en las cosas difíciles, ¿cómo podrá llegar al punto en el que pueda escribir SQL complejo para generar informes? Nunca he trabajado en una aplicación que no tenía necesidades de informes y, a menudo, bastante complicadas.

Los ORM tampoco son útiles para los procesos de BI o ETL en su mayor parte. Tampoco son útiles para consultas administrativas de la base de datos o para encontrar información en las tablas de auditoría y deshacer un conjunto particular de cambios en la base de datos. Hay muchas cosas que todavía se hacen con mayor eficacia con SQL. La aplicación que consulta la base de datos es una pequeña parte de lo que necesita consultarla en un entorno empresarial.

También veo muchas preguntas sobre cómo hacer algo usando un ORM que el afiche ya sabe cómo hacer en SQL. Es bueno aprender cosas nuevas, pero cuando están causando tiempo y esfuerzo adicionales sin una ganancia real sobre el método original (y a menudo una pérdida real de rendimiento), ¿por qué las estás usando aparte de que están "de moda" en este momento?

A veces, un cliente solo quiere una consulta rápida y fácil para devolver datos para un informe, exportación, descarga de datos, etc. y quiere esperar a que se desarrolle un programa completo.

Además, un buen programador de SQL siempre puede escribir un SQL más rápido y más eficiente que cualquier ORM que haya usado. Además, he descubierto que muchas personas simplemente tienen el punto ORM para los procedimientos almacenados, ignorando realmente los beneficios del ORM porque los ORM no son excelentes para procesos complejos.

Además, cuando se utiliza una base de datos como Oracle con un lenguaje de procedimiento muy rico y poderoso, puede hacer mucho sin necesitar un "programa". PL / SQL en Oracle en las manos correctas es muy rápido y eficiente.

Si quiere usar una base de datos usted mismo, sí. La mayoría de los ORM que intenté usar simplemente no eran suficientes o no cubrían mi base de datos. Además, ¿cómo va a solucionar problemas o escribir consultas personalizadas que no están cubiertas?

Todavía es necesario para escribir disparadores y procedimientos almacenados. Los procedimientos almacenados pueden haber caído en desgracia actualmente, pero siguen siendo muy útiles en algunas situaciones. Es posible que también se requiera SQL para algunas uniones de varias tablas particularmente complicadas.

Sí, puedes evitar escribir SQL. ¡Pero terminarás escribiendo HQL en su lugar (o Linq, o DQL ...)!

En serio, soy un gran admirador de los ORM, y creo que uno puede evitar el uso de SQL puro la mayor parte del tiempo. Pero debemos recordar que un ORM es solo una gran abstracción, y todas las grandes abstracciones se filtran ...

(Pero sobre el problema N + 1: esto está relacionado con la carga diferida, y la mayoría de las herramientas ORM tienen alguna forma de solicitar la carga ansiosa, evitando así ese problema en particular).

ORM solo te llevará a algún punto. Pero hay casos en los que tiene que ejecutar una consulta realmente complicada, con combinaciones complicadas, subconsultas, uniones, menos, funciones analíticas, etc. Ahí es cuando necesita SQL. Pero, ¿cómo se supone que debe escribir consultas complicadas cuando deja todas las consultas simples al ORM?

Incluso si no necesita escribirlo en su código, es bastante útil poder usarlo cuando tiene acceso de terminal a un servidor de base de datos.

Además, la mayor parte de lo que hace la programación de un desafío es trabajar dentro de las restricciones que los conjuntos de vida nosotros- menudo nos estamos trabajando con código antiguo, o versiones antiguas de bases de datos y no tienen la oportunidad de instalar la última ORM para cualquier lenguaje que estamos trabajando con. En esa situación, necesitará cualquier herramienta a su disposición.

Es posible que el resto del tiempo no necesite SQL para sus cosas CRUD, pero hay mucho más en SQL que simples consultas SELECT, INSERT, UPDATE y básica JOIN. Puede hacer cosas muy inteligentes con él y, aunque puede que no los use con frecuencia, es útil saber cuáles son.

Cada vez más, creo que nos encontraremos en un mundo posterior a SQL, sin embargo, la mayoría de los servicios en la nube usan almacenamiento de tablas no sql y para el trabajo simple de tipo CRUD, la potencia total de SQL es innecesaria. Pero eso no significa que no tendrá valor entenderlo.

Además, por supuesto, alguien tiene que saber lo suficiente para escribir un mejor sistema ORM si los actuales no son suficientes. Les ayudaría si supieran SQL ...

Para construir aplicaciones web a gran escala es completamente innecesario y puede hacer que las cosas sean mucho más estresantes y que pierdan el tiempo de lo necesario. La razón de esto es que cualquier aplicación a gran escala debería estar haciendo uso de una capa de persistencia de memoria (en RAM) que debería ser partes de almacenamiento en memoria caché de la base de datos que se usan con frecuencia.

Si tiene que hacer cosas con dispositivos móviles, etc. que no tienen mucha memoria para trabajar, donde la aplicación que se está programando se ejecuta como un "cliente" o aplicación independiente en un dispositivo móvil, tableta, etc. cosas como el uso de SQL siguen siendo comunes y son importantes porque la memoria en el dispositivo es tan pequeña que no puede almacenar en caché muchas cosas en la memoria.

La complejidad y la cantidad de SQL que escribo no es suficiente para hacer que el enganche de un marco ORM sea razonable.

(Escribo SQL tal vez una vez al mes, si)

Me encontré con muchos cuerpos grandes con DBA que temen activamente a los desarrolladores que usan herramientas ORM.

Son DBA que participan en el ajuste y el rendimiento.

Y sí, las herramientas ORM se pueden administrar para hacer cosas como esta, pero he visto lugares donde solo aceptarán un procedimiento almacenado (Servidor SQL) y le preguntarán qué está haciendo en él.

Además, las herramientas ORM pueden ser maltratadas y producir un SQL tan pobre como escribir el SQL usted mismo.

Un gran problema: DDL y migraciones de bases de datos. A veces necesita coser a mano esas cosas para actualizar cosas sin romper los datos existentes.