No tengo ninguna experiencia seria en SQL e incluso odio escribir SQL en lugar de LINQ. Estoy bastante contento con los ORMs.
Desde el punto de vista de los empleadores y del sector, ¿es importante saber SQL? ¿Tengo que dominarlo? ¿Las empresas que prefieren SQL puro en lugar de los marcos ORM son un "dinosaurio" en el mundo de la programación?
Esto es difícil de explicar a muchos programadores, porque si solo conoces básico SQL, entonces realmente no te da mucha ventaja sobre la muleta de un ORM. Sin embargo, los conceptos de SQL más avanzados son una parte crucial de la diferencia entre las aplicaciones que simplemente funcionan frente a las aplicaciones que son de alta calidad (en particular, rápidas y confiables).
Supongo que otra persona diseña las bases de datos para usted, porque hacer eso sin saber nada de SQL está más allá de lo normal. Pero incluso si solo se está desarrollando en contra de ellos, aquí hay solo una lista parcial de todas las cosas que los ORM aún tienden a hacer mal o no hacen nada:
La lista sigue y sigue: muchas de estas son cosas que un DBA novato nunca ha tenido que hacer, y un desarrollador novato nunca ha oído hablar de ellas, 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 y mapeo repetitivos y otros códigos de tuberías, por lo que no es vergonzoso usarlos y no Escucha a cualquiera que diga que son malvados. Pero definitivamente aún necesitas aprender y sí, incluso master SQL, y estar preparado para desplegar comandos / consultas de base de datos en bruto cuando el ORM no está esforzándose.¡Absolutamente! SQL sigue siendo la lengua franca de las bases de datos y, aunque puede hacer mucho con los ORM, debe comprender el 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í, todavía necesitas saber SQL. Los ORM son una abstracción muy importante , y no proporcionan acceso a toda la potencia de SQL. Para las 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 haber sido codificado en SQL en una hora. El conocimiento de SQL es muy valioso para cualquiera que escriba aplicaciones que utilizan una base de datos relacional.
La habilidad SQL es una habilidad indispensable en TI hoy. LINQ es una tecnología exclusiva de Microsoft. Los usos de SQL van más allá de la web y el desarrollo de aplicaciones cliente / servidor. No puedes modelar bases de datos y hacer ETL si no eres 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 lo califica como dinosaurio en muchos casos), pero son herramientas (para abstraer cosas que ya saben), no muletas (para evitar que aprenda).
Si se niega a aprender SQL, entonces no tiene nada que ver con tocar bases de datos SQL, ya sea con o sin un ORM, y debería encontrar otro tipo de trabajo.
Admito que soy un gran fanático de ORM y he estado predicando los beneficios de ORM durante años y he tenido mucho que decir sobre por qué ORM triunfa sobre SQL.
PERO ...
Debo admitir que SQL es totalmente necesario en el mundo real y que todos los desarrolladores deben tener un buen conocimiento de SQL.
Los procs de SQL son más rápidos que el ORM en casi todos los casos. A pesar de que puede optimizar la salida de ORM en la mayoría de los casos, también puede hacerlo en un segundo lugar cercano a los procedimientos SQL.
En algunas ocasiones, necesitas un SQL de alto rendimiento para obtener el resultado que necesitas, 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 el que tenga que optimizar algo complejo que está creando el ORM. En ese momento, generalmente tienes una consulta extremadamente compleja para descomponer. 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 empezar. ORMs en manos de una persona que entiende SQL: una buena herramienta. ORMs en manos de alguien que no sabe nada de SQL, desastre a punto de ocurrir.
Una de las razones por las que el SQL es fundamental para entender 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 operan de manera eficiente es por conjuntos. Debe aprender a pensar en conjuntos antes de intentar utilizar un ORM.
Me encuentro forzando manualmente las consultas en los marcos ORM más a menudo que no. Y mientras que la mayoría tiene su propio lenguaje de consulta, todos están inspirados en sql, el código se convierte en sql, y usted necesita entender qué está mal al leer ese sql cuando (no si, cuándo) las cosas salen mal o no funcionan bien. < br> Así que incluso si no está escribiendo sql directamente, entiéndalo más allá de un nivel básico (aunque probablemente no necesite aprender cosas sobre cómo escribir procedimientos almacenados, activadores, etc., si todo lo que va a hacer es acceder a las bases de datos) debe conocer el idioma lo suficiente como para entender el código generado y modificarlo según sea necesario.
Antes de hablar sobre la pregunta, una pequeña introducción primero; Me encantan los ORMs. Y odio el SQL. Me encantan los ORM porque ocultan el desagradable error para el usuario que es el SQL y proporcionan una buena forma integrada de lenguaje para 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 revisando la consulta. Por lo tanto, cuando uso SQL, siempre estoy alerta, y siempre tengo una intuición acerca de hacia dónde se dirige la complejidad de un componente.
Por otro lado, cuando uso ORMs, 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 apariencia inocente, que detrás de las escenas llaman uniones masivas y temibles de bases de datos, que destruyen el rendimiento.
Por eso para mí, la verdad está en algún punto intermedio. Me encanta usar los ORM, y continuaré haciéndolo, pero debo ser más cuidadoso y estudiar siempre las implicaciones (en el nivel de SQL) de cualquier llamada al método ORM. Saber 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 a ti mismo en el pie.
Si todo lo que debes hacer es interactuar con la base de datos solo a través de la aplicación que estás creando, probablemente no la necesites. En algunas compañías 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 sentencias de SQL para ver qué está pasando con sus datos.
Incluso con un ORM bueno y maduro, inevitablemente se encontrará con situaciones en las que emite un SQL ineficaz y hará que su vida sea mucho más fácil si puede asimilar lo que sucede en el SQL generado. Dicho esto, si usted es muy competente con el ORM y sabe cómo usar un generador de perfiles para su DB de elección, podría "simularlo hasta que lo logre".
La respuesta a todos estos tipos de preguntas ("¿necesito saber X?") es "aprende la primera vez que la necesitas, si alguna vez la necesitas".
Es importante, sin embargo, no caer en la trampa de hacer las cosas de manera menos eficiente porque no eres consciente de o no estás dispuesto a aprender la manera eficiente de hacerlo.
En este caso particular, por ejemplo, ¿qué hace si se da cuenta de que hubo un error en su programa que causó que el campo PostCount de su tabla de usuarios a veces sea inexacto?
Corriges el error y ahora tienes que actualizar el PostCount para todos los usuarios. ¿Cómo lo haces?
Si escribes un pequeño script usando ORM para hacer esto, entonces estás siendo muy ineficiente; una consulta SQL muy simple será suficiente.
¡Dado que estas situaciones son bastante comunes, me temo que hayas caído en la trampa descrita anteriormente!
Sí, todavía necesitas SQL.
No salte a la suposición de que algo "antiguo" es, de alguna manera, indigno de consideración. Las llamadas tecnologías "heredadas" son aquellas que todavía existen después de haber pasado la prueba del tiempo. No llamamos "heredado" a las computadoras de Wang, fallaron y desaparecieron.
Si me preguntas, ¿me molesta que mi banco 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 están utilizando DB2 SQL. Estoy mucho más feliz confiando en mi dinero allí, que en el software desarrollado en un lenguaje de moda del mes.
Los dinosaurios duraron en esta tierra mucho más de lo que los humanos hemos vivido. Y si lees Jurasic Park (sí, los libros son mejores que las películas), entonces te pregunto: ¿realmente quieres enfrentarte a un paquete de velociraptores muy inteligentes, o un T-Rex que nunca se rinde? No te muerdas por subestimar a los "dinosaurios". ;-)
Aparte 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 en las que las decisiones erróneas conducen a un gran impacto en el rendimiento. Creo firmemente en las abstracciones de bases de datos más poderosas en el código, y creo que linq, que vincula las operaciones de la base de datos con el lenguaje de programación, le brinda todas las herramientas del lenguaje (verificación de tipos, verificación de sintaxis, todas las cosas que le gustan de su lenguaje de programación) al mismo tiempo que le da suficiente poder para hacer lo que quiere es absolutamente fantástico. Desafortunadamente, todavía no siempre funciona. Eso significa que, si la capa de abstracción obtiene sus optimizaciones incorrectas, es posible que esté 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 "funciona": el rendimiento se convierte en el mayor problema de su aplicación. Eso significa que tienes que acercarte al metal y optimizar a mano.
Cuando llegamos al punto en que la manipulación de grandes conjuntos de datos requiere, por ejemplo, 3 ms cuando se hace a mano, y 100 ms cuando se deja que la capa de abstracción lo haga por usted, por supuesto, deje que la capa de abstracción lo maneje por usted. porque puede ser 30 veces más lento, pero aún es (lo que es probable, 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 en las que tiene un tiempo de respuesta de 200 ms, y cuando la capa de abstracción lo maneja, el algoritmo recibe 'solo' un acierto de rendimiento 10 veces, tiene una 2 segundos de retraso, y luego te importa mucho, ya que no va tan rápido, sino que se hace muy lento. Al ver que las soluciones de bases de datos relacionales no se escalan bien , No creas que esto se resolverá en dos o tres años. Esto significa que aún tendrá que ponerse al corriente durante bastante tiempo cuando se trata de bases de datos más grandes, o su aplicación será tan lenta que no podrá hacer frente a los competidores.
Lea otras preguntas en las etiquetas sql entity-framework orm