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

116

Ú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?

Travis
fuente
11
¿qué pasa con la seguridad de tipos?
johnny
3
¿Exactamente a quién están dirigidas estas capas de abstracción? SQL no es un lenguaje en el que todo el mundo sea bueno, por lo que podrían estar dirigidos a programadores mediocres. SQL en sí mismo no es en absoluto un buen lenguaje para un no programador.
David Thornley
27
@ David: Defina un lenguaje (informático) que sea "bueno para quienes no son programadores". Los no programadores, en mi humilde opinión, deben mantenerse alejados de los lenguajes de programación (y en el sentido más amplio de la palabra, SQL).
DevSolar
15
todas las respuestas también deberían ser wiki. Es una locura que preguntas y respuestas como estas obtengan tantos votos a favor. Pensé que esto era un foro técnico. puede resolver el problema de alguien proporcionando un código difícil de escribir y obtener uno o dos votos positivos, pero responder a una pregunta como esta y obtener un montón de votos positivos. eso es realmente tonto si me preguntas.
KM.
6
@KM: El problema con los votos es que dependen mucho de la cantidad de personas que lean una respuesta. Respondí muchas preguntas de NHibernate y Rhino Mocks que me tomó algún tiempo responder correctamente, y me aceptaron, pero ni un solo voto. Si responde algo trivial sobre C #, obtiene docenas de votos. Los votos simplemente no son justos. Sugiera algo en meta.stckoverflow, si sabe algo mejor.
Stefan Steinegger

Respuestas:

132

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.

Stefan Steinegger
fuente
31
"Simplemente diga lo que quiere, se lo entregamos lo antes posible". Ese enfoque declarativo es fantástico y en realidad es moderno (piense en LINQ). Es cierto que a veces es necesario ajustar la velocidad, y una alternativa de procedimiento a SQL podría ser útil entonces. Pero todavía usaría SQL declarativo la mayor parte del tiempo por simplicidad.
MarkJ
4
MarkJ: Recuerdo que reordené las cláusulas WHERE para optimizar las consultas en Oracle. Se resolvieron de abajo hacia arriba ... terrible.
Stefan Steinegger
16
Concuerdo completamente. La gente de TI tiene esta fascinación por las herramientas que no son de procedimiento. ¿No sería mucho más fácil si le dijera a la computadora lo que quiere y averigüe cómo hacerlo? Sí, si la computadora fuera lo suficientemente inteligente para hacer eso. Pero no lo es. Me gustaría si pudiera decirle a mi coche "Llévame a casa de la abuela" y me llevaría allí. Pero no es así, así que no dejo el volante y finjo que esto funcionará. Quizás algún día la tecnología esté ahí, o quizás sea un sueño imposible. Pero no está ahí hoy. (continúa ...)
Jay
12
Touché. Su respuesta describe perfectamente mis primeras frustraciones con SQL. Escribí mucho código de procedimiento porque no confiaba en SQL para generar un plan de ejecución eficiente. A medida que me familiaricé más con SQL, descubrí que, de hecho, es bastante bueno optimizando y que SQL escrito correctamente suele ejecutarse más rápido que mi código de procedimiento.
Kluge
5
@Jay y los otros escépticos de SQL. En mi experiencia, el problema es que para usar SQL de manera efectiva es necesario poder pensar en términos de conjuntos y no de manera procedimental, que es precisamente como se les enseña a pensar a la mayoría de los programadores. Usar SQL de manera efectiva realmente no es tan difícil y está al alcance de cualquier codificador competente (¡como cualquiera que lea SO!) Pero es necesario hacer el esfuerzo de saltar a pensar en lógica basada en conjuntos, y la mayoría de las veces la gente no lo hace. No te molestes (y actualmente estoy modificando un programa donde el codificador original ha hecho todo usando cursores precisamente por esta razón)
Cruachan
58

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!

Miguel Ventura
fuente
6
¡Muy diplomático! (¡Y es verdad, para empezar!)
Joseph Ferris
2
El problema es la inversión de la abstracción. SQL en una base de datos relacional es un entorno declarativo basado en conjuntos. Tiene un mayor nivel de abstracción que la programación imperativa, orientada a objetos o no.
Steven Huwig
2
Quizás sea así, Steven, pero en términos de la aplicación realiza una función de bajo nivel (incluso si lo hace de una manera de nivel extremadamente alto). No importa qué locas transformaciones hagas a nivel de base de datos, al final del día es un captador y configurador glorificado. O puede verlo de la manera opuesta, ya que es un nivel demasiado alto para mezclarlo con la aplicación y debe ser secuestrado y considerado por separado. En cualquier caso, mantener el SQL fuera del código de la aplicación principal tiene beneficios muy tangibles en términos de legibilidad y refactorización.
Publicado el
53

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.

Joonas Pulakka
fuente
19
No entiendo cómo las incompatibilidades de dialectos SQL pueden ser un "punto" tan grande contra SQL. Eso es como decir que C es una mierda porque no puedes simplemente compilar + ejecutar la misma fuente en diferentes distribuciones de Linux. Si, y es un gran IF, su empresa decide cambiar de proveedor de base de datos, es una ocurrencia grande y rara que tiene más partes móviles que simplemente reescribir algo de SQL.
Jeff Meatball Yang
7
No es un punto en contra de SQL, es un punto para las capas de abstracción. Por ejemplo, no se puede simplemente compilar + ejecutar el mismo código C en cualquier lugar, es un punto para más lenguajes indiferentes a la plataforma. Pero eso no convierte a SQL ni a C en una "mierda": las capas de abstracción corren por encima de las capas más profundas, de todos modos.
Joonas Pulakka
8
@Jeff: En C, las tareas comunes son parte del estándar. En SQL, es imposible paginar un conjunto de resultados sin entrar en SQL específico del proveedor.
Powerlord
4
Ah, y sobre la rareza de cambiar de proveedor de bases de datos: ¿de qué estás hablando? ¿La rareza de que una empresa cambie de sistema operativo hace que las soluciones multiplataforma sean irrelevantes? No siempre sabe de antemano en qué se ejecutará su producto, por lo que es mejor errar hacia soluciones más genéricas.
Joonas Pulakka
3
@Joonas: Supongo que quise decir que el (los) lenguaje (s) SQL no es (son) el problema. La pregunta es qué hace que SQL sea tan terrible, y mi reacción inicial, como la tuya, es que no lo es. Pero quería argumentar que acomodar diferentes dialectos no es realmente el objetivo de los ORM; los tendríamos incluso si solo tuviéramos un idioma estándar; creo que es más que necesitamos una forma de resolver los datos normalizados en un modelo OO.
Jeff Meatball Yang
36

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.

Steven Huwig
fuente
7
En cuanto al primer punto, los programadores no se sienten cómodos con nada más que un lenguaje imperativo. Será interesante durante los próximos años ver si y cómo el resurgimiento de la programación funcional hace alguna diferencia en esto. En este momento, hay mucho entusiasmo sobre lenguajes como Haskell, F # y Scala, lo que hace que los desarrolladores sean mucho más productivos. Este tipo de pensamiento "matemático" para programadores es muy similar al conocimiento del álgebra relacional y el cálculo relacional de tuplas que presupone SQL. ¡Quizás haya un resurgimiento del pensamiento basado en conjuntos de SQL nativo con el tiempo!
Trevor Tippins
Debo aclarar que me refiero a "aquellos programadores que no se sienten cómodos con nada más que la programación imperativa", no es que todos los programadores se sientan incómodos con ella.
Steven Huwig
+1, bien dicho. Y como alguien que pasó allí los primeros años como codificador profesional en la base de datos pre-relacional, me parece francamente sorprendente que alguien quiera volver a esa época, excepto para tareas especializadas. Un día dedicado a escribir código atravesando una estructura de árbol DL / 1 debería ser suficiente para convencer a cualquiera.
Cruachan
El problema es que hay muchos programadores compulsivos que prefieren lanzar unos cientos de líneas de código insípido en lugar de pensar en las cosas durante una hora más o menos.
Steven Huwig
No debería tener que pensar en las cosas durante una hora para escribir o comprender algunas líneas de código. Período.
Andrew
23

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.

Trevor Tippins
fuente
16

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.

Mark Schultheiss
fuente
11

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.

Nikolay R
fuente
2
Lo desafortunado es que resulta muy tentador introducir un código de procedimiento simple en un procedimiento almacenado. Y funciona bien. Hasta que alguien necesita para mantenerla / añadir algunas excepciones, etc ...
Brian Knoblauch
5
-1, eh, ese es precisamente el punto, SQL está diseñado para estar basado en conjuntos y ese es su poder. Pensar en términos de procedimiento significa que está pensando mal.
Cruachan
1
¡Este destornillador apesta! Es tan difícil clavarse las uñas con él.
Casey Rodarmor
9

Ú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:

Quassnoi
fuente
7

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!

Brian MacKay
fuente
7

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.

Liberado
fuente
6

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.

Jeff Sternal
fuente
¿Qué pasa con los esquemas de control de visibilidad?
Lógica de tres valores
5

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.

Peter Bailey
fuente
5

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.

Thomas
fuente
4

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.

tvanfosson
fuente
2
Es cierto, pero no necesita un ORM para esto
finnw
2
El uso de consultas parametrizadas es trivial cuando se escribe SQL directamente, siempre que tenga una capa de interfaz de base de datos decente (es decir, una que admita marcadores de posición). $dbh->do("DELETE FROM my_table WHERE some_value = ?", undef, $target_value); Ahí. Hecho.
Dave Sherohman
Nunca dije que no se pudieran escribir consultas parametrizadas con RAW SQL. Dije que usar SQL sin formato es más riesgoso ya que tienes que implementarlo tú mismo. He visto muchos casos de código SQL sin procesar donde la consulta no está parametrizada. Los ORM brindan este beneficio automáticamente.
tvanfosson
2
Es cierto, pero evitar la inyección de SQL es trivialmente fácil incluso sin declaraciones preparadas. En cada proyecto que hago, escribo una función simple que pone comillas alrededor de una cadena y escapa correctamente de las comillas incrustadas. Se necesitan unos quince minutos para escribir, incluso si no lo copio de un proyecto anterior. Luego lo uso para cada literal que inserto en una consulta. ¡Lo que me aturde es que los programadores no hacen esto! ¡No tome quince minutos para evitar una inyección SQL deliberada o, probablemente más común, accidental! ¡¿Por qué no?!
Jay
3
Jay, ¿esa "función simple que pone comillas alrededor de una cadena y escapa correctamente a las comillas incrustadas" tiene en cuenta el juego de caracteres actual en uso en el servidor?
ygrek
4

¿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.

Quisquilloso
fuente
4

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.

culebrón
fuente
3

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).

Joachim Sauer
fuente
¿Por qué es culpa de SQL que los lenguajes OO no se asignen bien? Cuando use un servicio, ajústese a su interfaz o no lo use.
KM.
2
Nadie dijo que es culpa de SQL. La lengua franca de DB-access es SQL. La lengua franca de la lógica empresarial se basa en OO. Esos dos no encajan perfectamente sin ayuda. Aquí no hay "fallas" ni "problemas", solo algunos requisitos ("hacerlos coincidir") y una solución ampliamente aceptada ("usar un OR-Mapper").
Joachim Sauer
Joachim Sauer dijo que SQL no es un lenguaje terrible, simplemente no funciona muy bien con otros. Para mí, suena como si alguien dijera que es culpa de SQL
KM.
1
@KM: ¿Estás diciendo que el francés y el alemán son malos idiomas? No juegan muy bien con el inglés.
David Thornley
3

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.

Nicolas Dorier
fuente
3

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.

Arrendajo
fuente
3
Toda la idea de la base de datos relacional fue producto de los fanáticos de las torres de marfil. Las primeras bases de datos relacionales tenían un rendimiento horrible en comparación con las bases de datos jerárquicas vigentes en ese momento, y tardaron mucho en establecerse. El poder de la abstracción fue tal que las bases de datos jerárquicas son esencialmente una cosa del pasado (aunque no es probable que todavía existan bases de datos IMS y CODASYL). Tenía que haber funcionado muy, muy bien.
David Thornley
1
Pero la gerencia no vería un "número cercano, si no cierto", verían un número incorrecto. Quizás ese cliente final deba mucho dinero. Entonces la gerencia estaría muy disgustada por ese número equivocado.
HTTP 410
RoadWarrior: Sí, es posible que tenga 10,000 clientes que le deben $ 10 cada uno y 1 cliente que le debe $ 10 millones. Pero si ese fuera el caso, cualquiera que solicite un informe de RA probablemente conocerá muy bien el nombre de ese cliente y sabrá exactamente qué está pasando con ellos. De acuerdo, estoy seguro de que hay ocasiones en las que ninguna respuesta es mejor que una respuesta que es tan poco confiable que no tiene sentido. Pero ese es mi punto: SQL está diseñado en torno a consideraciones teóricas como esa: un dogmático "cualquier cosa menos que la perfección no vale nada". ...
Jay
... En la vida real, el 95% de las veces, una respuesta aproximada es mucho mejor que una mirada en blanco. Cuando miro mi chequera, sé que es muy posible que haya cometido un error aritmético o que haya olvidado escribir un cheque. El saldo bien podría ser una aproximación. Pero aun así, si sé que tengo "alrededor de $ 1,000", no tendré reparos en extender un cheque por $ 50, y me daré cuenta de que extender un cheque por $ 10,000 será inútil.
Jay
Bueno, he dirigido un negocio, y nunca son 10K versus 1. IMX, es más parecido a 20 desconocidos por cada 100 conocidos (el principio de Pareto). Y algunos de esos 20 nos debían mucho dinero, razón por la cual la cantidad real estaba en disputa. Nuevamente, este es el principio de Pareto.
HTTP 410
3

• 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.

David R Tribble
fuente
1
¿Cómo hace eso que la sintaxis no sea ortogonal?
Amok
1
El lenguaje podría haber sido diseñado para que todas estas declaraciones imperativas tuvieran una sintaxis más común, especialmente entre las operaciones inserty update, que son casi idénticas semánticamente, pero sintácticamente completamente diferentes.
David R Tribble
2

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).

MusiGenesis
fuente
2
No entiendo cómo las incompatibilidades de dialectos SQL pueden ser un "punto" tan grande contra SQL. Eso es como decir que C es una mierda porque no puedes simplemente compilar + ejecutar la misma fuente en diferentes distribuciones de Linux.
Jeff Meatball Yang
1
@Jeff: En realidad, no creo que sea un gran punto en contra de SQL. Por eso dije "Estoy de acuerdo con tus puntos" y puse "terrible" entre comillas. Yo mismo prefiero SQL sobre las capas de abstracción de datos, aunque me alegro de que existan cosas como NHibernate porque son mucho mejores que la basura casera que solía proliferar.
MusiGenesis
1
Es cierto, yo también uso capas de abstracción, supongo que quise decir que, para mí, el lenguaje SQL no es el problema, es la transformación de datos normalizados en objetos, razón por la cual las capas de abstracción son útiles.
Jeff Meatball Yang
2

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.

Ovolko
fuente
tratar con instancias de objetos en la memoria es bastante diferente a los datos que se almacenan físicamente en una base de datos. hay más problemas para corregir diseños deficientes y posiblemente variaciones masivas en el rendimiento basadas en "pequeñas cosas"
KM.
2

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).

Jeff Albóndiga Yang
fuente
2

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.

Señor de poder
fuente
5
¿Por qué intenta apuntar a todos esos entornos con su código? Escríbeme código C para subprocesos que funcione en Mac OS 9, Windows NT, OS / 2 Warp y Solaris.
Steven Huwig
2
@Steven Huwig: Probablemente usaría una capa de abstracción para hacerlo por mí ... que es exactamente lo que estaba haciendo la pregunta.
Powerlord
@Steven: Sucede que uso marcos y capas de abstracción para bastantes cosas en las que necesito ser independiente de la plataforma. Sin embargo, la independencia de la base de datos es mucho más importante en la mayoría de los casos. Incluso si solo está entregando su software para que se ejecute en Windows, una vez que lo venda a corporaciones más grandes, se encontrará con todo, desde "Preferimos OSS, ¿admite MySQL" hasta "Usamos Oracle | MSSQL | lo que sea como un estándar corporativo, lo apoyan ".
Fredrik
2

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.
estupito
fuente
1

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.

NateDSaint
fuente
Puedes ahorrarte bastante ese dolor simplemente no usando MySQL. ;)
Steven Huwig
1

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.
DigitalRoss
fuente
0

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 .

Joseph Ferris
fuente
1
Votante negativo: ¿le importaría explicar por qué o simplemente hacer clic en el botón abajo para todo lo que no está de acuerdo?
Joseph Ferris
0

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.

Adriaan
fuente