Supongamos que estamos usando Java o Python para acceder a la base de datos. Entonces, ¿se considera una pérdida de tiempo e innecesario aprender el tipo de estructuras de datos y objetos que se utilizan dentro de SQL?

Responda en referencia a la industria del software. Por favor, trate de decir en qué casos será bueno tener conocimiento de tales cosas.

Tengo una discusión con alguien que dice que no es necesario aprender tales cosas.

Hace unos años trabajé en una aplicación escrita por alguien que claramente nunca había aprendido cómo funcionan las bases de datos SQL. Me dieron un informe del problema para solucionarlo: la página principal de resumen de estado, que siempre había sido lenta, ahora había comenzado a ser tan lenta que estaba llegando al tiempo de espera de ejecución del script del servidor (de 3 minutos) durante el procesamiento. Parecía que a medida que aumentaba el número de clientes en el sistema, el tiempo para representar la página de estado aumentaba de forma cuadrática .

No tardé mucho en notar el problema, que era que la página usaba una consulta que amalgamaba datos de dos tablas diferentes, ninguna de las cuales tenía ningún índice . Debido a que cada tabla tenía un tamaño que crecía en O (n) con el número de clientes, la consulta tardaba O (n ^ 2) en ejecutarse porque estaba obteniendo cada fila de la primera tabla, y para cada una de esas filas estaba buscando cada fila de la segunda tabla para compararlas.

Resolver el problema tomó minutos, y cualquiera que entienda cómo funcionan las bases de datos SQL podría haberlo hecho con la misma rapidez . El autor original no lo hizo, por lo que dejó una solución totalmente inadecuada.

Debe comprender cómo (al menos en términos generales) funciona una tecnología para evitar cometer errores horrendos como este.

No descarte la posibilidad de que deba ingresar a la base de datos y consultarla directamente como parte de un proceso de depuración. Si alguna vez termina haciendo eso, definitivamente querrá saber todo sobre la tecnología de la base de datos y cómo está estructurada su base de datos en particular. Quizás no suceda. Pero si lo hace (y en mi experiencia siempre lo hace en algún momento) necesitará ese conocimiento.

Pero supongamos que nunca tendrá que buscar directamente en la base de datos por ningún motivo. Digamos que está utilizando el ORM de una manera consistente con todas las mejores prácticas establecidas por la comunidad. Usted podría hacer una aplicación performant sin grandes errores / cuello de botella / ineficiencias wrt a los datos. Pero si realmente no comprende la base de datos subyacente, realmente no entendería por qué está haciendo las cosas como está. Peor, realmente noComprenda cómo se aplican las mejores prácticas a su caso de uso específico. Estos hechos deben sembrar algunas dudas de que está creando la solución óptima. Su solución puede funcionar, pero no podrá decir "esta es la mejor solución" con ninguna confianza real. Si no puedes decir eso, no eres un gran activo a los ojos de tu empresa y si lo dices y te equivocas, te parecerá terrible.

Más allá de los problemas filosóficos que tengo sobre no aprender los fundamentos de su pila de tecnología, trato con razones tangibles para conocer su pila de arriba a abajo a diario. En mi empresa tenemos un gran monolito que maneja enormes cantidades de datos. Las cosas están bien modeladas, pero hay docenas y docenas de tipos de objetos en la aplicación y las relaciones entre ellos son una increíble red de claves foráneas y tablas de asociación. Francamente, si nunca mira el SQL y simplemente se sumerge en la aplicación (aunque todo está modelado correctamente en la aplicación y usa el ORM y las mejores prácticas establecidas para ese ORM), descubra cómo obtener este bit de información dado este otro bit por aquí puede ser una tarea casi imposible. Pero si puede sumergirse en la base de datos, puede ver todos los campos en cada modelo, siga las conexiones entre las tablas, calcule una ruta de una pieza a otra, pruébela con una consulta, luego busque los modelos adecuados para hacerlo a través del ORM de manera rápida y eficiente. No sería la mitad del activo para mi empresa que soy si no tuviera un alto nivel de comodidad con SQL puro.

Solo hasta cierto punto

Como desarrollador de software, probablemente tendrá que consultar y actualizar la base de datos, y saber cómo funciona la base de datos es fundamental para evitar malas consultas, uniones ineficientes, etc. Es posible que tenga un DBA dedicado que pueda decidir dónde agregar índices y particionar la base de datos, pero no puede contar con ella, no en pequeñas empresas y no siempre en grandes.

sin embargo

Si bien debe saber qué son los índices y cómo se deben usar, probablemente no necesite saber cómo funcionan internamente. Los detalles de implementación internos son solo eso: detalles de implementación.

Saber cómo verificar un plan de consulta SQL y construir su código en consecuencia es parte de la API que expone su DB. ¿Conociendo los algoritmos internos y las estructuras de datos que utiliza para lograrlo? No. Tanto. Como analogía, debería conocer las implicaciones de rendimiento de guardar archivos en el disco. No necesito preocuparme por cómo se implementa mi sistema de archivos.

Sin embargo a la Sin embargo

Si, como muestran los comentarios aclaratorios, la pregunta es acerca de comprender el acceso a la base de datos frente a depender exclusivamente de ORM y otras abstracciones de código, la respuesta es abrumadoramente "sí, debe conocer el acceso a la base de datos". No todos los proyectos usan o pueden usar un ORM, y los ORM no son ideales para ciertas tareas (informes, inserciones masivas y más).

¡Vale la pena el tiempo! Ser un desarrollador full stack le permite producir de manera eficiente soluciones de valor agregado. Con demasiada frecuencia he visto fallas en la comunicación y desarrollo en silos ... Triplique el tiempo de desarrollo y la mitad de la calidad.

Al final del día, cuantas más habilidades tengas, más valioso serás.

Si profesas no saber nada acerca de los autos , ¿estaría feliz de que repares los frenos del mío? Yo creo que no.

Las bases de datos son notablemente diferentes de las estructuras de datos con las que está acostumbrado a trabajar en la programación. Tienen sus propias rarezas e idiosincrasias y otras cosas que lo morderán en el rendimiento de la aplicación si no los comprende.

Me he encontrado con personas con esta mentalidad de "No necesito saber bases de datos"; la mayoría de ellos consideran las bases de datos como nada más que hojas de cálculo y como resultado producen aplicaciones que funcionan terriblemente mal.

Dicho esto, no necesita saber cómo funcionan las bases de datos internamente .

No llegar a conocer las cosas lógico; Tablas, Índices, Vistas y similares.

No se deje atrapar por los detalles de implementación de cómo un DBMS particular maneja estas cosas; que todo lo hacen de manera diferente el uno del otro (y, a veces entre las versiones de sí mismos !), por lo que una "visión general" en general le servirá mejor.

Necesitas absolutamente saberlo. Por ejemplo, si su base de datos está almacenando fechas, necesita saber qué tipo de precisión puede esperar. Si está almacenando una marca de tiempo en un DATEcampo, debe saber si la base de datos va a truncar su valor al segundo más cercano (o peor, al día más cercano). También debe saber que los valores que provienen de una NUMBER(9,2)columna deben almacenarse en una variable de punto flotante, mientras que los de a NUMBER(15,0)pueden almacenarse como enteros. También puede resultarle útil saber que las pequeñas rarezas, como las CHARcolumnas de Oracle, se rellenan en blanco a la longitud especificada, mientras que las VARCHAR2columnas no. Y su LONGtipo de datos en realidad almacena cadenas de longitud variable, no números.

Cada base de datos tiene sus peculiaridades, y debe saber cuáles son (o al menos qué buscar).

Comprender cómo funcionan las cosas debajo del capó lo ayudará a depurar sus consultas por consideraciones de rendimiento y almacenamiento.

Por ejemplo, una consulta de rango funcionará mejor con un tipo de índice B-tree. Y al hacer uniones, puede agregar pistas al motor de consultas sobre si usar uniones HASH o MERGE. Y desde el punto de vista físico, puede distribuir tablas en una base de datos a diferentes particiones de disco físico para minimizar la contención de la cabeza (probablemente aún sea adecuado incluso con SSD).

Primero debes tener claro qué es SQL y qué no es. SQL es un lenguaje de consulta y lenguaje de manipulación de datos utilizado para acceder y manipular datos en una base de datos relacional. Pero el esquema y los objetos de datos (tablas, columnas, índices, restricciones) en la base de datos no están "en SQL", SQL es solo un lenguaje posible para consultar y manipular los datos.

Para poder trabajar eficazmente con una base de datos relacional, debe comprender tablas, columnas, tipos de datos, claves primarias, claves externas e índices. También debe comprender los conceptos básicos de las consultas: proyección, filtros, uniones. Necesita comprender los conceptos básicos de la normalización.

Pero ninguna de estas cosas en principio requiere que toque SQL. Puede diseñar el esquema de la base de datos en un diseñador de GUI, y puede escribir consultas y actualizaciones en algún otro idioma como SqlAlchemy para Python o Linq para .net. Algunos incluso argumentan que estos lenguajes son una representación más pura del modelo relacional que SQL.

Entonces, en teoría, tu amigo tiene razón: no necesitas aprender SQL. Pero aún necesita aprender cómo funcionan las bases de datos relacionales, y cuando sabe eso, SQL es bastante fácil de aprender, ya que es solo una sintaxis.

Si bien no es necesario, es bastante conveniente conocer SQL, ya que puede consultar cualquier base de datos directamente en SQL sin la necesidad de una capa de traducción separada. Y dado que todos los tutoriales, libros y ejemplos usan SQL, será difícil evitar aprenderlo.

Me encontré con un problema en el que los números de serie se almacenaban como números decimales de 10 dígitos en una base de datos y se leía en enteros de 32 bits en Java. Esto estuvo bien hasta que alcanzamos nuestro primer número de serie que era mayor que 2G, por lo que no podía representarse en el entero de 32 bits con signo de Java. La comprensión de los tipos de datos DB podría haber evitado este problema.