¿Es importante SQL si conozco bien los marcos ORM? [cerrado]

No tengo ninguna experiencia seria en SQL e incluso odio escribir SQL en lugar de LINQ. Estoy bastante contento con los ORM.

Desde el punto de vista de los empleadores y el sector, ¿es importante conocer SQL? ¿Tengo que dominarlo? ¿Son las empresas que prefieren los frameworks SQL puro sobre ORM un "dinosaurio" en el mundo de la programación?

Esto es difícil de explicar a muchos programadores, porque si solo conoces SQL básico, entonces realmente no te da una gran ventaja sobre la muleta de un ORM. Sin embargo, los conceptos SQL más avanzados son una parte crucial de la diferencia entre las aplicaciones que simplemente funcionan y las aplicaciones de alta calidad (en particular, rápidas y confiables).

Estoy asumiendo que alguien más diseños de las bases de datos para usted, porque hacer eso sin saber nada de SQL es un poco más allá de los límites. Pero incluso si solo se está desarrollando contra ellos, aquí hay una lista parcial de todas las cosas que los ORM aún tienden a hacer mal o no hacen nada:

• Consultas recursivas y / o jerárquicas
• Parámetros opcionales (particularmente traduciéndolos en predicados de rango)
• Tipos de datos definidos por el usuario.
• Tipos específicos de plataforma (jerarquía de SQL y TVP, matrices de Oracle y tablas anidadas, etc.)
• Inserciones / actualizaciones / actualizaciones / eliminaciones por lotes
• Indice de pistas
• Sugerencias de bloqueo (especialmente bloqueos de actualización y lecturas sucias)
• Manejo de errores
• Uniones externas: sus conjuntos de resultados se asignan mal al modelo OOP, muchos ORM tienen su propio lenguaje de consulta, pero eso es similar a conocer el propio SQL;
• Modularización a través de procedimientos almacenados y UDF, especialmente UDF en línea y consultas CROSS APPLY
• Uso de OUTPUT / RETURNING para organizar datos en varias tablas
• Consultas de paginación eficientes
• Consultas basadas en funciones de ventanas (rownum, rango, particiones)

La lista sigue y sigue: muchas de estas cosas son cosas que un DBA novato nunca ha tenido que hacer, y un desarrollador novato nunca ha oído hablar, pero son muy importantes en aplicaciones a gran escala.

Los ORM son realmente excelentes para acelerar el código SQL realmente aburrido , es decir, todo el CRUD repetitivo y el mapeo y otros códigos de plomería, por lo que no hay ninguna vergüenza en usarlos y no escuchar a nadie que diga que son malvados. Pero definitivamente aún necesita aprender y sí, incluso dominar SQL, y estar preparado para desplegarse en comandos / consultas de base de datos sin procesar cuando el ORM no está ejerciendo su peso.

¡Absolutamente! SQL sigue siendo la lengua franca de las bases de datos y, aunque puede hacer mucho con ORM, debe comprender SQL para comprender las decisiones que toman los ORM y el SQL que generan. Además, todavía hay muchas cosas que tiene que hacer con SQL personalizado y procedimientos almacenados también. Lo sentimos, no hay almuerzo gratis.

Sí, aún necesita saber SQL. Los ORM son una abstracción muy permeable y no proporcionan acceso a la potencia total de SQL. Para aplicaciones de juguete , puede estar bien con un conocimiento limitado de SQL. Para las aplicaciones empresariales, deberá comprender la base de datos para obtener un rendimiento decente del ORM. También hay muchas tareas que se realizan mucho más fácilmente con SQL que con un lenguaje de aplicación. He visto a los programadores de Java pasar días escribiendo código para hacer algo que podría haberse codificado en SQL en una hora. El conocimiento de SQL es muy valioso para cualquiera que escriba aplicaciones que usen una base de datos relacional.

La habilidad SQL es una habilidad imprescindible en TI hoy. LINQ es una tecnología exclusiva de Microsoft. Los usos de SQL van más allá del desarrollo de aplicaciones web y cliente / servidor. No puede modelar bases de datos y hacer ETL si no es bueno con SQL. Es posible que no necesite dominar los dialectos de SQL utilizados en ORACLE y SQL Server para sus productos de Data Warehous, pero debe conocer el SQL estándar. Los conceptos básicos de SQL son simples, hay toneladas de material para comenzar.

Si está interactuando con una base de datos SQL, debe comprender el SQL que está generando el ORM. Debe comprender los conceptos inherentes a las bases de datos SQL y debe comprender lo que su ORM no puede hacer por usted. Los ORM hacen la vida más fácil (y sí, creo que trabajar sin uno te califica como dinosaurio en muchos casos), pero son herramientas (para abstraer cosas que sabes), no muletas (para evitar que aprendas).

Si se niega a aprender SQL, no tiene nada que ver con las bases de datos SQL, con o sin un ORM, y debería encontrar otro tipo de trabajo.

Admito que soy un fanático de ORM y que he estado predicando los beneficios de ORM durante años y tenía mucho que decir sobre por qué ORM triunfa sobre SQL.

PERO...

Tengo que admitir que SQL se requiere total y completamente en el mundo real y todos los desarrolladores deben tener una buena comprensión de SQL.

Los procesos SQL son más rápidos que el ORM en casi todos los casos. Aunque en la mayoría de los casos también puede optimizar el resultado de ORM, hacer que esté en un segundo lugar cercano a los procesos de SQL.

En ocasiones, necesita un SQL de alta resistencia para obtener el resultado que necesita, y estas consultas monstruosas son más fáciles y rápidas de crear en los procesos SQL.

Solo mis dos bits.

Llegará un momento en que deberá optimizar algo complejo que el ORM está creando. En ese punto, generalmente tiene una consulta extremadamente compleja que desglosar. Si nunca aprendió lo básico, ¿cómo puede esperar comenzar a aprender SQL con las cosas avanzadas? No entenderás lo suficiente como para comenzar. ORM en manos de una persona que entiende SQL: una buena herramienta. ORM en manos de alguien que no conoce SQL en absoluto: desastre a punto de ocurrir.

Una de las razones por las cuales SQL es crítico para comprender las bases de datos es que los programadores de aplicaciones no piensan naturalmente en términos de conjuntos de datos. Pero la única forma en que las bases de datos funcionan de manera eficiente es por conjuntos. Debe aprender a pensar en conjuntos antes de intentar usar un ORM.

Me encuentro forzando manualmente las consultas en los marcos ORM la mayoría de las veces. Y aunque la mayoría tiene su propio lenguaje de consulta, todos están inspirados en sql, el código se convierte en sql, y debe comprender qué está mal al leer ese sql cuando (no si, cuándo) las cosas salen mal o funcionan mal.
Entonces, incluso si no está escribiendo SQL directamente, entendiéndolo más allá de un nivel básico (aunque probablemente no necesite aprender cosas sobre cómo escribir procedimientos almacenados, disparadores, etc. si todo lo que va a hacer es acceder a las bases de datos) debe conocer el idioma lo suficiente como para comprender el código generado y ajustarlo según sea necesario.

Antes de hablar sobre la pregunta, primero una pequeña introducción; Me encantan los ORM. Y odio el SQL. Me encantan los ORM porque ocultan el desorden amigable para el usuario que es SQL y proporcionan una buena forma integrada de lenguaje de tratar con la base de datos.

Sin embargo, debo admitir que SQL tiene muchos beneficios, y el más grande es la precisión. Casi puedo discutir sobre la complejidad de una consulta SQL, sin un conocimiento detallado del esquema de la base de datos subyacente, simplemente pasando por la consulta. Por lo tanto, cuando uso SQL, siempre estoy alerta y siempre tengo una intuición sobre hacia dónde se dirige la complejidad de un componente.

Por otro lado, cuando uso ORM, estoy tan abrumado por la facilidad de integración de la base de datos, que literalmente olvido que incluso hay una base de datos. Esto me ha jodido varias veces. Muchas veces en el pasado, he llamado métodos ORM de aspecto inocente, que detrás de escena llaman uniones de bases de datos masivas y aterradoras, que destruyen el rendimiento.

Por eso, para mí, la verdad está en algún punto intermedio. Me encanta usar ORM, y continuaré haciéndolo, pero debo ser más cuidadoso y siempre estudiar las implicaciones (en el nivel SQL) de cualquier llamada al método ORM. Conocer las implicaciones de una capa de abstracción es oro puro en este negocio, y justifica el uso de la abstracción. Cualquier otra cosa, es como dispararte en el pie.

Si todo lo que tiene que hacer es interactuar con la base de datos solo a través de la aplicación que está creando, probablemente no la necesite. En algunas empresas más pequeñas o equipos de desarrolladores, es posible que tenga que hacer algo de soporte. Es mucho más fácil conectarse a la base de datos de un cliente y ejecutar algunas instrucciones sql para ver qué sucede con sus datos.

Incluso con un ORM bueno y maduro, inevitablemente se encontrará con situaciones en las que está emitiendo un SQL ineficiente y le hará la vida mucho más fácil si puede asimilar lo que está sucediendo en el SQL generado. Dicho esto, si eres muy hábil con el ORM y sabes cómo usar un generador de perfiles para tu base de datos de elección, puedes fácilmente "simularlo hasta que lo hagas".

La respuesta a todos estos tipos de preguntas ("¿necesito saber X?") Es "aprende la primera vez que la necesites, si alguna vez la necesitas".

Sin embargo, es importante no caer en la trampa de hacer las cosas de manera menos eficiente porque no está al tanto o no está dispuesto a aprender la forma eficiente de hacerlo.

En este caso particular, por ejemplo, ¿qué hacer si se da cuenta de que hubo un error en su programa que ocasionó que el PostCountcampo de su tabla de usuario a veces fuera inexacto.

Corrige el error y ahora tiene que actualizar PostCount para todos los usuarios. ¿Cómo lo haces?

Si escribe un pequeño script usando ORM para hacer esto, entonces está siendo muy ineficiente; una consulta SQL muy simple servirá.

¡Dado que estas situaciones son bastante comunes, temo que caigas en la trampa descrita anteriormente!

Sí, aún necesitas SQL.

No salte a la suposición de que algo "viejo" es de alguna manera indigno de consideración. Las llamadas tecnologías "heredadas" son aquellas que aún existen después de haber resistido la prueba del tiempo. No llamamos a las computadoras Wang "legado", fallaron y desaparecieron.

Si me preguntas, ¿me molesta que mi banco probablemente esté usando COBOL en un mainframe o IBM i? Absolutamente no. Estas son tecnologías sólidas, probadas y verdaderas. Adivina qué, en su mayoría utilizan DB2 SQL. Estoy mucho más feliz confiando en mi dinero allí, que en el software desarrollado en un idioma de moda del mes.

Los dinosaurios perduraron en esta tierra mucho más tiempo que los humanos. Y si lees Jurasic Park (sí, los libros son mejores que las películas), entonces te pregunto, ¿de verdad quieres enfrentarte a un grupo de velociraptores hiper-inteligentes, o un T-Rex obstinado que nunca se rinde? No se muerda subestimando a los "dinosaurios". ;-)

Además de los juegos y la investigación (principalmente estadística), con los que no tengo experiencia, parece que el acceso a la base de datos y las operaciones son una de las pocas áreas donde las decisiones incorrectas conducen a un gran impacto en el rendimiento. Creo firmemente en las abstracciones de bases de datos más potentes en el código, y creo en linq, que vincula las operaciones de la base de datos con el lenguaje de programación, brindándole todas las herramientas del lenguaje (verificación de tipo, verificación de sintaxis, todo lo que le gusta de su lenguaje de programación) mientras le da mucho poder para hacer lo que quiere es absolutamente fabuloso. Desafortunadamente, todavía no siempre funciona. Eso significa que si la capa de abstracción se equivoca en sus optimizaciones y puede estar esperando segundos en lugar de microsegundos, o minutos en lugar de segundos para su resultado. Dado que estos son tiempos muy notables, debe optimizarlos, o su aplicación no "funcionará": el rendimiento se convierte en el mayor problema de su aplicación. Eso significa que debe acercarse al metal y optimizar la mano.

Cuando lleguemos al punto de que manipular grandes conjuntos de datos toma, por ejemplo, 3 ms cuando se hace a mano, y 100 ms cuando deja que la capa de abstracción lo haga por usted, de todos modos, deje que la capa de abstracción lo maneje por usted, porque podría ser 30 veces más lento, pero aún es (probablemente, para la mayoría de las aplicaciones) lo suficientemente rápido. Sin embargo, la realidad de la situación es que cuando busca soluciones optimizadas a mano donde tiene un tiempo de respuesta de 200 ms, y cuando la capa de abstracción lo maneja por usted, el algoritmo recibe "solo" un golpe de rendimiento 10 veces, tiene un 2 segundos de retraso, y luego te importa mucho, ya que pasa de no tan rápido a dolorosamente lento. Ver que las soluciones de bases de datos relacionales no escalan bien, No creo que esto se resuelva en dos o tres años. Esto significa que aún tendrá que llegar al metal desnudo durante bastante tiempo cuando se trata de bases de datos más grandes, o su aplicación será tan lenta que no podrá resistir a los competidores.