¿Por qué no hay amor por SQL? [cerrado]

Últimamente he escuchado mucho que SQL es un lenguaje terrible, y parece que cada marco bajo el sol viene empaquetado previamente con una capa de abstracción de base de datos.

Sin embargo, en mi experiencia, SQL es a menudo la forma mucho más fácil, más versátil y más amigable para el programador de administrar la entrada y salida de datos. Cada capa de abstracción que he usado parece ser un enfoque marcadamente limitado sin ningún beneficio real.

¿Qué hace que SQL sea tan terrible y por qué son valiosas las capas de abstracción de bases de datos?

Esto es en parte subjetivo. Entonces esta es mi opinión:

SQL tiene un estilo de lenguaje pseudo-natural . Los inventores creían que podían crear un idioma como el inglés y que las consultas a la base de datos serían muy sencillas. Un terrible error. SQL es muy difícil de entender, excepto en casos triviales.

SQL es declarativo. No puede decirle a la base de datos cómo debe hacer las cosas, solo lo que quiere como resultado. Esto sería perfecto y muy poderoso, si no tuvieras que preocuparte por el rendimiento. Así que terminas escribiendo SQL, leyendo planes de ejecución, reformulando SQL tratando de influir en el plan de ejecución, y te preguntas por qué no puedes escribir el plan de ejecución tú mismo .

Otro problema del lenguaje declarativo es que algunos problemas son más fáciles de resolver de manera imperativa. Entonces, puede escribirlo en otro idioma (necesitará SQL estándar y probablemente una capa de acceso a datos) o utilizando extensiones de idioma específicas del proveedor, por ejemplo, escribiendo procedimientos almacenados y similares. Al hacerlo, probablemente encontrará que está utilizando uno de los peores idiomas que haya visto, porque nunca fue diseñado para ser utilizado como un lenguaje imperativo.

SQL es muy antiguo . SQL se ha estandarizado, pero demasiado tarde, muchos proveedores ya desarrollaron sus extensiones de lenguaje. Entonces SQL terminó en docenas de dialectos. Es por eso que las aplicaciones no son portátiles y una razón para tener una capa de abstracción de base de datos.

Pero es cierto, no hay alternativas viables. Entonces, todos usaremos SQL durante los próximos años.

Aparte de todo lo dicho, una tecnología no tiene por qué ser mala para que una capa de abstracción sea valiosa .

Si está haciendo un script o una aplicación muy simple, puede permitirse mezclar llamadas SQL en su código donde quiera. Sin embargo, si está haciendo un sistema complejo, aislar las llamadas a la base de datos en módulos separados es una buena práctica y, por lo tanto, es aislar su código SQL. Mejora la legibilidad, el mantenimiento y la capacidad de prueba de su código. Le permite adaptar rápidamente su sistema a los cambios en el modelo de la base de datos sin dividir todas las cosas de alto nivel, etc.

SQL es genial. ¡Las capas de abstracción sobre él lo hacen aún más grande!

Un punto de las capas de abstracción es el hecho de que las implementaciones de SQL tienden a ser más o menos incompatibles entre sí, ya que el estándar es ligeramente ambiguo, y también porque la mayoría de los proveedores han agregado sus propios extras (no estándar) allí. Es decir, SQL escrito para una base de datos MySQL podría no funcionar de manera muy similar con, digamos, una base de datos Oracle, incluso si "debería".

Sin embargo, estoy de acuerdo en que SQL es mucho mejor que la mayoría de las capas de abstracción que existen. No es culpa de SQL que se use para cosas para las que no fue diseñado.

SQL se habla mal de varias fuentes:

• Programadores que no se sienten cómodos con nada más que un lenguaje imperativo.
• Consultores que tienen que lidiar con muchos productos incompatibles basados ​​en SQL a diario
• Proveedores de bases de datos no relacionales que intentan romper el dominio de los proveedores de bases de datos relacionales en el mercado
• Expertos en bases de datos relacionales como Chris Date que ven las implementaciones actuales de SQL como insuficientes

Si se apega a un producto DBMS, definitivamente estoy de acuerdo en que las bases de datos SQL son más versátiles y de mayor calidad que sus competidores, al menos hasta que llegue a una barrera de escalabilidad intrínseca en el modelo. Pero, ¿realmente está tratando de escribir el próximo Twitter o simplemente está tratando de mantener algunos datos contables organizados y consistentes?

La crítica de SQL es a menudo un sustituto de las críticas a los RDBMS. Lo que los críticos de los RDBMS parecen no entender es que resuelven bastante bien una gran clase de problemas informáticos y que están aquí para hacernos la vida más fácil, no más difícil.

Si se tomaran en serio la crítica de SQL, respaldarían esfuerzos como Tutorial D y Dataphor.

No es tan terrible. Es una tendencia desafortunada en esta industria desechar la tecnología confiable anterior cuando surge un nuevo "paradigma". Al final del día, lo más probable es que estos marcos utilicen SQL para comunicarse con la base de datos, entonces, ¿cómo puede ser TAN malo? Dicho esto, tener una capa de abstracción "estándar" significa que un desarrollador puede centrarse en el código de la aplicación y no en el código SQL. Sin una capa tan estándar, probablemente escribiría una capa liviana cada vez que desarrolle un sistema, lo cual es una pérdida de esfuerzo.

SQL está diseñado para la gestión y consulta de datos basados ​​en SET. A menudo se usa para hacer más y los casos extremos a veces generan frustración.

El USO real de SQL puede verse TAN afectado por el diseño de la base de datos base que el SQL puede no ser el problema, pero el diseño sí podría, y cuando agrega el código heredado asociado con un mal diseño, los cambios son más impactantes y costosos de implementar ( a nadie le gusta volver atrás y "arreglar" cosas que están "funcionando" y cumpliendo objetivos)

Los carpinteros pueden martillar clavos con martillos, aserrar madera con sierras y alisar tablas con cepillos. ES posible "aserrar" usando martillos y aviones, pero es frustrante.

No diré que es terrible. No es adecuado para algunas tareas. Por ejemplo: no se puede escribir un buen código de procedimiento con SQL. Una vez me vi obligado a trabajar con la manipulación de conjuntos con SQL. Me tomó un fin de semana entero darme cuenta de eso.

SQL fue diseñado para álgebra relacional, ahí es donde debería usarse.

Últimamente he escuchado mucho que SQL es un lenguaje terrible, y parece que cada marco bajo el sol viene empaquetado previamente con una capa de abstracción de base de datos.

Tenga en cuenta que estas capas solo convierten sus propias cosas en SQL. Para la mayoría de los proveedores de bases de datos SQLes la única forma de comunicarse con el motor.

Sin embargo, en mi experiencia, SQL es a menudo la forma mucho más fácil, más versátil y más amigable para el programador de administrar la entrada y salida de datos. Cada capa de abstracción que he usado parece ser un enfoque marcadamente limitado sin ningún beneficio real.

… Razón por la que acabo de describir arriba.

Las capas de la base de datos no agregan nada, solo lo limitan . Hacen que las consultas sean discutiblemente más simples pero nunca más eficientes.

Por definición, no hay nada en las capas de la base de datos que no esté incluido SQL.

¿Qué hace SQLque sea tan terrible y por qué son valiosas las capas de abstracción de bases de datos?

SQL es un lenguaje agradable, sin embargo, se necesita un poco de giro para trabajar con él.

En teoria, SQL es declarativo, es decir, declaras lo que quieres obtener y el motor lo proporciona de la forma más rápida posible.

En la práctica, hay muchas formas de formular una consulta correcta (es decir, la consulta que devuelve resultados correctos).

Los optimizadores pueden construir un castillo de Lego a partir de algunos algoritmos predefinidos (sí, son múltiples), pero simplemente no pueden crear nuevos algoritmos. Todavía se necesita un SQLdesarrollador para ayudarlos.

Sin embargo, algunas personas esperan que el optimizador produzca "el mejor plan posible", no "el mejor plan disponible para esta consulta con una implementación determinada del SQLmotor".

Y como todos sabemos, cuando el programa de computadora no cumple con las expectativas de la gente, se culpa al programa, no a las expectativas.

En la mayoría de los casos, sin embargo, reformular una consulta puede producir el mejor plan posible. Hay tareas en las que es imposible, sin embargo, con las nuevas y crecientes mejoras deSQL estos casos, cada vez son menos.

Sería bueno, sin embargo, si los proveedores proporcionaran algún acceso de bajo nivel a funciones como "obtener el rango de índice", "obtener una fila por rowid", etc., como los Ccompiladores le permiten incrustar el ensamblado directamente en el lenguaje.

Recientemente escribí un artículo sobre esto en mi blog:

• Doble pensamiento en SQL

Soy un gran defensor de ORM y todavía creo que SQL es muy útil, aunque ciertamente es posible hacer cosas terribles con él (como cualquier otra cosa). .

Veo SQL como un lenguaje súper eficiente que no tiene como prioridades la reutilización o mantenibilidad / refactorización de código.

Así que el procesamiento ultrarrápido es la prioridad. Y eso es aceptable. Solo debe tener en cuenta las compensaciones, que para mí son considerables.

Desde un punto de vista estético, como lenguaje siento que le faltan algunas cosas, ya que no tiene conceptos de OO, etc., me parece un código de procedimiento de la vieja escuela. Pero es de lejos la forma más rápida de hacer ciertas cosas, ¡y ese es un nicho poderoso!

Yo diría que una capa de abstracción de base de datos incluida con un marco es algo bueno porque resuelve dos problemas muy importantes:

1. Mantiene el código distinto. Al colocar SQL en otra capa, que generalmente es muy delgada y solo debe realizar los conceptos básicos de consulta y transferencia de resultados (de una manera estandarizada), mantiene su aplicación libre del desorden de SQL. Es la misma razón por la que los desarrolladores web (deberían) poner CSS y Javascript en archivos separados. Si puede evitarlo, no mezcle sus idiomas .

2. Muchos programadores son simplemente malos en el uso de SQL. Por alguna razón, una gran cantidad de desarrolladores (especialmente desarrolladores web) parecen ser muy, muy malos en el uso de SQL o RDBMS en general. Tratan la base de datos (y SQL por extensión) como el pequeño intermediario sucio por el que tienen que pasar para acceder a los datos. Esto lleva a bases de datos extremadamente mal pensadas sin índices, tablas apiladas encima de tablas de manera dudosa y consultas muy mal escritas. O peor aún, intentan ser demasiado generales (Expert System, ¿alguien?) Y no pueden relacionar razonablemente los datos de una manera significativa.

Desafortunadamente, a veces la forma en que alguien intenta resolver un problema y las herramientas que utiliza, ya sea por ignorancia, terquedad o algún otro rasgo, están en oposición directa entre sí, y la buena suerte intenta convencerlos de esto. Como tal, además de ser una buena práctica, considero que una capa de abstracción de base de datos es una especie de red de seguridad, ya que no solo mantiene el SQL fuera de los ojos del desarrollador pobre, sino que hace que su código sea significativamente más fácil de refactorizar. ya que todas las consultas están en un solo lugar.

SQL es excelente para ciertos tipos de tareas, especialmente para manipular y recuperar conjuntos de datos.

Sin embargo, SQL falta (o solo implementa parcialmente) varias herramientas importantes para administrar el cambio y la complejidad:

• Encapsulamiento : los mecanismos de encapsulación de SQL son burdos. Cuando escribe código SQL, debe saber todo sobre la implementación de sus datos. Esto limita la cantidad de abstracción que puede lograr.

• Polimorfismo : si desea realizar la misma operación en diferentes tablas, debe escribir el código dos veces. (Se puede mitigar esto con un uso imaginativo de puntos de vista).

• Control de visibilidad : no existe un mecanismo SQL estándar para ocultar partes del código entre sí o agruparlas en unidades lógicas, por lo que cada tabla, procedimiento, etc. es accesible desde todos los demás, incluso cuando no es deseable.

• Modularidad y control de versiones

Finalmente, codificar manualmente las operaciones CRUD en SQL (y escribir el código para conectarlo al resto de la aplicación) es repetitivo y propenso a errores.

Una capa de abstracción moderna proporciona todas esas características y nos permite usar SQL donde es más efectivo mientras oculta los detalles de implementación repetitivos y disruptivos. Proporciona herramientas para ayudar a superar el desajuste de impedancia relacional de objetos que complica el acceso a los datos en el desarrollo de software orientado a objetos.

SQL se basa en la teoría de conjuntos, mientras que la mayoría de los lenguajes de alto nivel están orientados a objetos en estos días. A los programadores de objetos normalmente les gusta pensar en objetos y tienen que hacer un cambio mental para usar herramientas basadas en conjuntos para almacenar sus objetos. En general, es mucho más natural (para el programador de OO) simplemente cortar el código en el lenguaje de su elección y hacer algo como object.save u object.delete en el código de la aplicación en lugar de tener que escribir consultas SQL y llamar a la base de datos para lograr el mismo resultado.

Por supuesto, a veces para cosas complejas, SQL es más fácil de usar y más eficiente, por lo que es bueno tener un manejo de ambos tipos de tecnología.

En mi opinión, el problema que veo que la gente tiene con SQL no tiene nada que ver con el diseño relacional ni con el lenguaje SQL en sí. Tiene que ver con la disciplina de modelar la capa de datos, que en muchos aspectos es fundamentalmente diferente a modelar una capa o interfaz empresarial. Los errores en el modelado en la capa de presentación generalmente son mucho más fáciles de corregir que en la capa de datos donde tiene múltiples aplicaciones usando la base de datos. Estos problemas son los mismos que se encuentran al modelar una capa de servicio en diseños SOA, en los que debe tener en cuenta los consumidores actuales de su servicio y los contratos de entrada y salida.

SQL fue diseñado para interactuar con modelos de bases de datos relacionales. Hay otros modelos de datos que existen desde hace algún tiempo, pero la disciplina de diseñar correctamente la capa de datos existe independientemente del modelo teórico utilizado y, por lo tanto, las dificultades que los desarrolladores suelen tener con SQL suelen estar relacionadas con los intentos de imponer un modelo no relacional. modelo de datos en un producto de base de datos relacional.

Por un lado, hacen que sea trivial el uso de consultas parametrizadas, lo que lo protege de los ataques de inyección SQL. El uso de SQL sin formato, desde esta perspectiva, es más riesgoso, es decir, es más fácil equivocarse desde una perspectiva de seguridad. También suelen presentar una perspectiva orientada a objetos en su base de datos, lo que le evita tener que hacer esta traducción.

¿Escuchaste mucho recientemente? Espero que no confunda esto con el movimiento NoSql. Hasta donde yo sé, es principalmente un grupo de personas que usan NoSql para aplicaciones web de alta escalabilidad y parecen haber olvidado que SQL es una herramienta eficaz en un escenario que no es de "aplicación web de alta escalabilidad".

El negocio de la capa de abstracción consiste simplemente en resolver la diferencia entre el código orientado a objetos y el código basado en conjuntos de tablas, como a SQL le gusta hablar. Por lo general, esto da como resultado la escritura de muchas placas de caldera y un código de transición aburrido entre los dos. ORM automatiza esto y, por lo tanto, ahorra tiempo a la gente de negocios.

Para un programador experimentado de SQL, los aspectos negativos son

• Verbosidad
• Como muchos han dicho aquí, SQL es declarativo, lo que significa que la optimización no es directa . Es como un rally en comparación con las carreras de circuito.
• Marcos que intentan abordar todos los dialectos posibles y no admiten atajos de ninguno de ellos
• Sin control de versiones fácil.

Para otros, las razones son que

• algunos programadores son malos en SQL. Probablemente porque SQL opera con conjuntos, mientras que los lenguajes de programación funcionan en paradigma de objeto o funcional. Pensar en conjuntos (unión, producto, intersección) es una cuestión de hábitos que algunas personas no tienen.
• algunas operaciones no se explican por sí mismas: es decir, al principio no está claro dónde y tener filtros de diferentes conjuntos.
• hay demasiados dialectos

El objetivo principal de los marcos SQL es reducir su escritura. De alguna manera lo hacen, pero con demasiada frecuencia solo para consultas muy simples. Si intenta hacer algo complejo, debe usar cadenas y escribir mucho. Los marcos que intentan manejar todo lo posible, como SQL Alchemy, se vuelven demasiado grandes, como otro lenguaje de programación.

[actualización el 26.06.10] Recientemente trabajé con el módulo ORM de Django . Este es el único marco SQL digno que he visto. Y este hace que trabajar con cosas sea mucho. Sin embargo, los agregados complejos son un poco más difíciles.

SQL no es un lenguaje terrible, simplemente no funciona muy bien con otros a veces.

Si, por ejemplo, tiene un sistema que quiere representar todas las entidades como objetos en algún lenguaje de OO u otro, entonces combinar esto con SQL sin ningún tipo de capa de abstracción puede resultar bastante complicado. No existe una manera fácil de asignar una consulta SQL compleja al mundo OO. Para aliviar la tensión entre esos mundos se insertan capas adicionales de abstracción (un OR-Mapper, por ejemplo).

SQL es un lenguaje realmente bueno para la manipulación de datos. Desde la perspectiva de un desarrollador, lo que no me gusta es que cambiar la base de datos no rompe su código en el momento de la compilación ... Así que uso la abstracción que agrega esta característica al precio del rendimiento y tal vez la expresividad del lenguaje SQL , porque en la mayoría de las aplicaciones no necesita todo lo que tiene SQL.

La otra razón por la que se odia SQL es por las bases de datos relacionales.

El teorema CAP se vuelve popular:

¿Qué objetivos podría desear de un sistema de datos compartidos?

• Fuerte consistencia: todos los clientes ven la misma vista, incluso en presencia de actualizaciones
• Alta disponibilidad: todos los clientes pueden encontrar alguna réplica de los datos, incluso en presencia de fallas
• Tolerancia a la partición: las propiedades del sistema se mantienen incluso cuando el sistema está particionado

El teorema establece que siempre puede tener solo dos de las tres propiedades CAP al mismo tiempo

La base de datos relacional aborda una fuerte consistencia y tolerancia a la partición.

Entonces, cada vez más personas se dan cuenta de que la base de datos relacional no es la solución milagrosa, y cada vez más personas comienzan a rechazarla a favor de la alta disponibilidad, porque la alta disponibilidad hace que el escalado horizontal sea más fácil. El escalado horizontal gana popularidad porque hemos alcanzado el límite de la ley de Moore , por lo que la mejor manera de escalar es agregar más máquina.

Si se rechaza la base de datos relacional, también se rechaza SQL.

SQL tiene muchos defectos, como han señalado algunos otros carteles aquí. Aún así, prefiero usar SQL sobre muchas de las herramientas que la gente ofrece como alternativas, porque las "simplificaciones" son a menudo más complicadas de lo que se suponía que debían simplificar.

Mi teoría es que SQL fue inventado por un grupo de esquiadores azules de torres de marfil. Toda la estructura no procesal. Suena genial: dime qué quieres en lugar de cómo quieres hacerlo. Pero en la práctica, a menudo es más fácil dar los pasos. A menudo, esto parece tratar de dar instrucciones de mantenimiento al automóvil describiendo cómo debe funcionar el automóvil cuando haya terminado. Sí, podrías decir: "Quiero que el auto vuelva a recorrer 30 millas por galón y que corra con este zumbido como este ... hmmmm ... y, etc." Pero, ¿no sería más fácil para todos simplemente decir, "Reemplazar las bujías"? E incluso cuando averigua cómo expresar una consulta compleja en términos no procedimentales, el motor de la base de datos a menudo presenta un plan de ejecución muy ineficiente para llegar allí.

¡Y el manejo de nulos me vuelve loco! Sí, teóricamente debe haber sonado genial cuando alguien dijo: "Oye, si nulo significa desconocido, entonces agregar un valor desconocido a un valor conocido debería dar un valor desconocido. Después de todo, por definición, no tenemos idea de cuál es el valor desconocido . " Teóricamente, absolutamente cierto. En la práctica, si tenemos 10,000 clientes y sabemos exactamente cuánto dinero nos deben 9,999, pero hay alguna duda sobre la cantidad adeuda por el último, y la gerencia dice: "¿Cuál es el total de nuestras cuentas por cobrar?", Sí, matemáticamente correcto la respuesta es "No lo sé". Pero la respuesta práctica es "calculamos $ 4,327,287.42 pero una cuenta está en cuestión, por lo que el número no es exacto". Estoy seguro de que la gerencia preferiría acercarse, si no cierto, a un número fijo que una mirada en blanco.

Dicho todo esto, todavía prefiero usar SQL que alguna capa construida sobre SQL, que simplemente crea otro conjunto completo de cosas que necesito aprender, y luego tengo que saber que, en última instancia, esto se traducirá a SQL y, a veces, Puedo confiar en que hará la traducción de manera correcta y eficiente, pero cuando las cosas se vuelven complejas no puedo, así que ahora tengo que conocer la capa adicional, todavía tengo que saber SQL y tengo que saber cómo se traducirá. para que pueda engañar a la capa para que engañe a SQL para que haga lo correcto. Arggh.

• Cada proveedor extiende la sintaxis SQL para satisfacer sus necesidades. Entonces, a menos que esté haciendo cosas bastante simples, su código SQL no es portátil.

• La sintaxis de SQL no es ortogonal; por ejemplo, las declaraciones select, insert, update,y deletetienen una estructura sintáctica completamente diferente.

Estoy de acuerdo con sus puntos, pero para responder a su pregunta, una cosa que hace que SQL sea tan "terrible" es la falta de estandarización completa de T-SQL entre los proveedores de bases de datos (Sql Server, Oracle, etc.), lo que hace que sea poco probable que el código SQL sea completamente portátil. Las capas de abstracción de bases de datos resuelven este problema, aunque con un costo de rendimiento (a veces uno muy severo).

Vivir con SQL puro realmente puede ser un infierno de mantenimiento. Para mí, la mayor ventaja de los ORM es la capacidad de refactorizar el código de forma segura sin los tediosos procedimientos de "refactorización de DB". Hay buenos marcos de prueba unitarios y herramientas de refactorización para lenguajes OO, pero todavía tengo que ver la contraparte de Resharper para SQL, por ejemplo.

Aún así, todos los DAL tienen SQL detrás de escena, y aún necesita saberlo para comprender qué está sucediendo en su base de datos, pero el trabajo diario con una buena capa de abstracción se vuelve más fácil.

Si no ha utilizado demasiado SQL, creo que el principal problema es la falta de buenas herramientas de desarrollo.

Si tiene mucha experiencia con SQL, en un momento u otro, se habrá sentido frustrado por la falta de control sobre el plan de ejecución. Este es un problema inherente a la forma en que se especificó SQL a los proveedores. Creo que SQL necesita convertirse en un lenguaje más robusto para aprovechar realmente la tecnología subyacente (que es muy poderosa).

Rápido, escríbeme SQL para paginar un conjunto de datos que funcione en MySQL, Oracle, MSSQL, PostgreSQL y DB2.

Oh, cierto, SQL estándar no define ningún operador para limitar la cantidad de resultados que regresan y en qué fila comenzar.

No hay amor por SQL porque SQL es malo en sintaxis, semántica y uso actual. Lo explicaré:

• su sintaxis es una metralla de cobol, toda la crítica de cobol se aplica aquí (en menor grado, para ser justos). Tratar de ser un lenguaje natural sin intentar interpretarlo crea una sintaxis arbitraria (es DROP TABLE o DROP, UPDATE TABLE, UPDATE o UPDATE IN, DELETE o DELETE FROM ...) y monstruosidades sintácticas como SELECT (cuántas páginas se llena?)
• La semántica también es profundamente defectuosa, Date lo explica con gran detalle, pero será suficiente señalar que una lógica booleana de tres valores no se ajusta realmente a un álgebra relacional donde una fila solo puede ser o no parte de una tabla
• Tener un lenguaje de programación como interfaz principal (y a menudo única) para las bases de datos resultó ser una mala elección y creó una nueva categoría de fallas de seguridad.

Estoy de acuerdo con la mayoría de las publicaciones aquí en que el debate sobre la utilidad de SQL es principalmente subjetivo, pero creo que es más subjetivo en la naturaleza de sus necesidades comerciales.

Los lenguajes declarativos, como ha señalado Stefan Steinegger, son buenos para especificar lo que quieres, no cómo quieres hacerlo. Esto significa que sus diversas implementaciones de SQL son decentes desde una perspectiva de alto nivel: es decir, si todo lo que desea es obtener algunos datos y nada más importa, puede satisfacerse escribiendo consultas relativamente simples y eligiendo la implementación de SQL. que es adecuado para ti.

Si trabaja en un nivel mucho más "inferior" y necesita optimizar todo eso usted mismo, está lejos de ser ideal. El uso de una capa adicional de abstracción puede ayudar, pero si lo que realmente está tratando de hacer es especificar los métodos para optimizar las consultas, etc., es un poco contrario a la intuición agregar un intermediario al intentar optimizar.

El mayor problema que tengo con SQL es como otros lenguajes "estandarizados", hay muy pocos estándares reales. Casi preferiría tener que aprender un idioma completamente nuevo entre Sybase y MySQL para no confundir las dos convenciones.

Si bien SQL hace el trabajo, ciertamente tiene problemas ...

• trata de ser simultáneamente la abstracción de alto y bajo nivel , y eso es ... extraño. Quizás debería haber sido dos o más estándares en diferentes niveles.
• es un gran fracaso como estándar . Muchas cosas salen mal cuando un estándar se agita en todo, pide demasiado a las implementaciones, pide muy poco o, por alguna razón, no logra el objetivo parcialmente social de motivar a los proveedores e implementadores para producir implementaciones completas interoperables estrictamente conformes. Ciertamente, no se puede decir que SQL haya hecho nada de eso. Mire algunos otros estándares y observe que el éxito o el fracaso del estándar es claramente un factor de la cooperación útil lograda:
  • RS-232 ( malo , no lo suficientemente especificado, incluso qué pin transmite y qué pin recibe es opcional, sheesh. Puede cumplir pero aún así no lograr nada. Probabilidad de interoperabilidad exitosa: muy baja hasta que IBM PC se convirtió en un estándar útil de facto .)
  • IEEE 754-1985 punto flotante ( incorrecto , extralimitación: ni una sola supercomputadora o estación de trabajo científica o microprocesador RISC lo adoptó jamás, aunque finalmente, después de 20 años, pudimos implementarlo bien en HW. Al menos el mundo finalmente creció en él).
  • C89, C99, PCI, USB, Java ( bueno , ya sea estándar o de especificaciones, lograron motivar el cumplimiento estricto de casi todos, y ese cumplimiento resultó en una interoperación exitosa).
• no pudo ser seleccionado para posiblemente la base de datos más importante del mundo . Si bien esto es más un punto de datos que una razón, el hecho de que Google Bigtable no sea SQL ni relacional es una especie de anti-logro para SQL.

No me disgusta SQL, pero tampoco quiero tener que escribirlo como parte de lo que estoy desarrollando. El DAL no se trata de la velocidad de comercialización; de hecho, nunca pensé que habría una implementación de DAL que fuera más rápida que las consultas directas desde el código. Pero el objetivo del DAL es abstraer . La abstracción tiene un costo, y aquí es donde llevará más tiempo implementarlo.

Sin embargo, los beneficios son enormes. Escribiendo pruebas nativas alrededor del código, usando clases expresivas, conjuntos de datos fuertemente tipados, etc. Usamos una especie de "DAL", que es una implementación de DDD pura usando Genéricos en C #. Así que tenemos repositorios genéricos, implementaciones de unidades de trabajo (transacciones basadas en código) y separación lógica. Podemos hacer cosas como simular nuestros conjuntos de datos con poco esfuerzo y desarrollarlos antes de las implementaciones de bases de datos. Hubo un costo inicial en la construcción de dicho marco, pero es muy bueno que la lógica empresarial vuelva a ser la estrella del espectáculo.. Ahora consumimos datos como recurso y los tratamos en el lenguaje que usamos de forma nativa en el código. Un beneficio adicional de este enfoque es la clara separación que proporciona. Ya no veo una consulta de base de datos en una página web, por ejemplo. Sí, esa página necesita datos. Sí, la base de datos está involucrada. Pero ahora, no importa de dónde extraiga los datos, hay un (y solo un) lugar para ingresar al código y encontrarlo. Tal vez no sea un gran problema en proyectos más pequeños, pero cuando tiene cientos de páginas en un sitio o docenas de ventanas en una aplicación de escritorio, realmente puede apreciarlo.

Como desarrollador, fui contratado para implementar los requisitos de la empresa utilizando mis habilidades lógicas y analíticas, y la implementación de nuestro marco me permite ser más productivo ahora. Como gerente, prefiero que mis desarrolladores utilicen sus habilidades lógicas y analíticas para resolver problemas que escribir SQL. El hecho de que podamos construir una aplicación completa que use la base de datos sin tener la base de datos hasta más cerca del final del ciclo de desarrollo es algo hermoso. No pretende ser un golpe contra los profesionales de bases de datos. A veces, la implementación de una base de datos es más compleja que la solución. SQL (y en nuestro caso, Vistas y Procesos almacenados, específicamente) son un punto de abstracción donde el código puede consumir datos como un servicio. En tiendas donde existe una separación definida entre los equipos de datos y de desarrollo, esto ayuda a eliminar estar en un patrón de espera esperando la implementación y los cambios de la base de datos. Los desarrolladores pueden centrarse en el dominio del problema sin pasar el mouse sobre un DBA y el DBA puede centrarse en la implementación correcta sin que un desarrollador lo necesiteahora mismo .

Muchas publicaciones aquí parecen argumentar que SQL es malo porque no tiene características de "optimización de código" y que no tienes control sobre los planes de ejecución.

Los motores SQL son buenos para elaborar un plan de ejecución para una instrucción escrita, orientada hacia los datos , el contenido real . Si desea echar un vistazo más allá del lado de la programación, verá que hay más datos que bytes que se pasan entre niveles de aplicación.