¿SQL es solo para una posición de nivel de entrada?

Al igual que muchas disciplinas, puede aprender y usar SQL en un nivel principiante, intermedio o avanzado.

Usando una analogía, piense en un mecánico. Un mecánico de nivel de entrada sabría cómo realizar tareas básicas de mantenimiento. Y un mecánico de nivel avanzado estaría afinando autos de carrera.

Pero ambos usan los mismos conjuntos de herramientas (como llaves). Cada uno tiene un nivel diferente de conocimiento, por ejemplo, el motor y la transmisión, lo que les permite usar sus herramientas para resolver problemas más avanzados.

De la misma manera, un desarrollador de bases de datos puede estar armado con el mismo conjunto de herramientas (T-SQL), pero aquellos con conocimiento avanzado del motor de almacenamiento, optimizador de consultas, teoría basada en conjuntos, etc., son capaces de abordar desafíos más avanzados y desarrollar Soluciones más elaboradas.

Respuesta corta: no .

No estoy seguro de dónde surgió esta idea, pero casi cualquier persona que use bases de datos relacionales debe conocer SQL muy bien, y cualquiera que haga algo no trivial en un entorno informático complejo tendrá que interactuar con las bases de datos en algún momento u otro.

Por lo tanto, poco importa si está utilizando SQL de Java o Python en una aplicación web, utilizando SQL incorporado en R (lenguaje de programación) como científico de datos, o simplemente escribiendo consultas en informes, terminará utilizando SQL en algún punto.

También tenga en cuenta que las herramientas y los marcos de mapeo relacional de objetos como Hibernate (Java) no sustituyen el conocimiento de SQL. Pueden ayudar con la productividad del programador, pero confiar demasiado en ellos puede ser una muleta peligrosa y puede impedir que los desarrolladores comprendan el esquema que están utilizando. (Y tienen una tendencia a no funcionar bien cuando los conjuntos de datos crecen).

Incluso la mayoría de los sistemas “NoSQL” utilizan algún tipo de lenguaje de consulta, y ese lenguaje de consulta con frecuencia se parece muchísimo a, er, SQL, por lo que si conoce SQL, tendrá una ventaja inicial para conocer cosas como el lenguaje de consulta de Apache Cassandra ” CQL “o el lenguaje de consulta” PigLatin “de Pig (herramienta de programación) del mundo Hadoop.

En el mundo de hoy, SQL juega un papel muy clave para un desarrollador. Pero desafortunadamente, no muchas personas que son buenas en la codificación de procedimientos son capaces de comprender SQL tan bien. Cuando la mayoría de las personas se sienten cómodas con SQL básico como Seleccionar, Insertar y Actualizar, cualquier cosa más allá de eso, no encontrará muchos expertos. La gente está tratando de evitar SQL mediante LINQ, herramientas de consulta, etc., pero ninguno de ellos puede reemplazar a alguien que pueda escribir consultas para obtener las respuestas. Definitivamente ayuda para una posición de nivel de salida para dominar SQL, ya que va a vivir más tiempo, no hay muchas variantes entre varias bases de datos, y los trabajos son muchos en el lado de los datos.

No.

Mis programadores más antiguos escriben SQL como una parte clave de lo que hacen.

Incluso yo, como CTO, tengo un documento en mi escritorio titulado “consultas SQL útiles” que son cosas que he escrito para consultas ad hoc, pero que no se usan lo suficiente como para que valga la pena convertirlas en informes completos que los no programadores pueden solo corre.

SQL, el lenguaje, es una cosa. No es ciencia espacial. Pero escribir consultas que se ejecutan de manera eficiente en el sistema de base de datos en el que se supone que se ejecutan es otra cosa. Eso lleva años de experiencia. La experiencia obviamente no es nada para los puestos de nivel de entrada.

En mi opinión, SQL podría ser un lenguaje de programación declarativo que puede manejar datos y no hay mejores alternativas en este momento de la escritura.
Sus habilidades, experiencia y puesto de trabajo no se pueden medir por si está utilizando SQL o no.

Yo diría que las personas de nivel de entrada no deberían tener demasiado acceso a SQL, ya que es probable que eliminen los recursos que usan los analistas más experimentados.
Si una persona de nivel de entrada también desestima SQL (y la oportunidad de usarlo), diría que es hora de que esa persona sea despedida / reevaluada.