Ocasionalmente escucho cosas sobre cómo SQL apesta y no es un buen lenguaje, pero nunca escucho mucho sobre alternativas a él. Entonces, ¿hay otros buenos lenguajes que tienen el mismo propósito (acceso a la base de datos) y qué los hace mejores que SQL? ¿Existen buenas bases de datos que utilicen este lenguaje alternativo?
EDITAR: Estoy familiarizado con SQL y lo uso todo el tiempo. No tengo ningún problema con eso, solo estoy interesado en cualquier alternativa que pueda existir y por qué a la gente le gustan más.
Tampoco estoy buscando tipos alternativos de bases de datos (el movimiento NoSQL), solo diferentes formas de acceder a las bases de datos.
Respuestas:
Ciertamente estoy de acuerdo en que es difícil trabajar con la sintaxis de SQL, tanto desde el punto de vista de generarla automáticamente como desde el punto de vista de analizarla, y no es el estilo de lenguaje que escribiríamos hoy si estuviéramos diseñando SQL para las demandas que imponemos. en él hoy. No creo que encontraríamos tantas palabras clave variadas si diseñáramos el lenguaje hoy, sospecho que la sintaxis de unión sería diferente, funciones como
GROUP_CONCATtendrían una sintaxis más regular en lugar de colocar más palabras clave en el medio de los paréntesis para controlar su comportamiento ... cree su propia lista de incoherencias y redundancias en SQL que le gustaría / espera ver suavizada si rediseñamos el lenguaje hoy.No existen alternativas a SQL para hablar con bases de datos relacionales (es decir, SQL como protocolo), pero existen muchas alternativas a escribir SQL en sus aplicaciones. Estas alternativas se han implementado en forma de frontends para trabajar con bases de datos relacionales. Algunos ejemplos de una interfaz incluyen:
Creo que el tema subyacente hoy en día es que, en lugar de reemplazar SQL con un nuevo lenguaje de consulta, estamos creando interfaces específicas del lenguaje para ocultar el SQL en nuestros lenguajes de programación cotidianos habituales, y tratando SQL como el protocolo para hablar con relacionales bases de datos.
fuente
Eche un vistazo a esta lista.
El lenguaje de consulta Hibernate es probablemente el más común. La ventaja de Hibernate es que los objetos se asignan muy fácilmente (casi automáticamente) a la base de datos relacional, y el desarrollador no tiene que dedicar mucho tiempo al diseño de la base de datos. Visite el sitio web de Hibernate para obtener más información. Estoy seguro de que otros intervendrán con otros lenguajes de consulta interesantes ...
Por supuesto, hay muchas cosas NoSQL por ahí, pero mencionas específicamente que no estás interesado en ellas.
fuente
SQL tiene más de treinta años. Los conocimientos sobre "qué características hacen de algo un lenguaje 'bueno' y cuáles lo convierten en uno 'malo'" han evolucionado más rápidamente que el propio SQL.
Además, SQL no es un lenguaje que se ajuste a los estándares actuales de "lo que se necesita para ser relacional", por lo que SQL simplemente no es un lenguaje relacional para arrancar.
Lo invito a reflexionar sobre la posibilidad de que esté tratando de escuchar solo en los lugares equivocados (es decir, en la industria comercial de DBMS exclusivamente).
Date & Darwen describen las características a las que debe ajustarse un lenguaje moderno de manipulación de datos en su "Tercer Manifiesto", cuya versión más reciente se establece en su libro "Bases de datos, tipos y el modelo relacional".
Si por "bueno" te refieres a algo como "fuerza industrial", entonces no. Lo más cercano disponible probablemente sería Dataphor.
El proyecto Rel ofrece una implementación para el lenguaje Tutorial D definido en "Bases de datos, tipos y el modelo relacional", pero el objetivo principal actual de Rel es ser de naturaleza educativa.
Mi proyecto SIRA_PRISE ofrece una implementación para la gestión de datos "verdaderamente relacional", pero dudo en etiquetarlo también como "una implementación de un lenguaje".
Y, por supuesto, también puede examinar algunas cosas no relacionales, como algunos han propuesto, pero personalmente descarto la gestión de datos no relacionales como varias décadas de regresión tecnológica. No vale la pena considerarlo, eso es.
Ah, y por cierto, un sistema de software que se utiliza para administrar bases de datos no es "una base de datos", sino "un sistema de administración de bases de datos", "DBMS" para abreviar. Al igual que una fotografía no es lo mismo que una cámara, y si está hablando de cámaras y desea evitar confusiones, entonces debería usar la palabra adecuada "cámaras" en lugar de "fotografía".
fuente
Quizás esté pensando en las críticas que C. Date y sus amigos han pronunciado contra las bases de datos relacionales existentes y SQL; dicen que los sistemas y el lenguaje no son 100% relacionales y deberían serlo. Realmente no veo ningún problema real aquí; Por lo que puedo ver, puede tener un sistema 100% relacional, si lo desea, simplemente disciplinando la forma en que usa SQL.
Lo que personalmente sigo encontrando es la falta de poder expresivo que SQL hereda de su base teórica, el álgebra relacional. Un problema es la falta de soporte para el uso de la ordenación de dominios, que se encuentra cuando trabaja con datos marcados por fechas, marcas de tiempo, etc. Una vez intenté hacer una aplicación de informes completamente en SQL simple en una base de datos llena de marcas de tiempo y simplemente no fue factible. Otro es la falta de soporte para el recorrido de la ruta: la mayoría de mis datos parecen gráficos dirigidos en los que necesito atravesar rutas, y SQL no puede hacerlo. (Carece de "cierre transitivo". SQL-1999 puede hacerlo con "subconsultas recursivas", pero todavía no las he visto en uso real. También hay varios trucos para hacer que SQL se adapte, pero son feos). Estos problemas son también discutido por algunos de los escritos de Date, por cierto.
Recientemente me señalaron .QL, que parece abordar muy bien el problema del cierre transitivo, pero no sé si puede resolver el problema con dominios ordenados.
fuente
Respuesta directa: no creo que haya ningún competidor serio por ahí. DBase y sus imitadores (Foxpro, Codebase, etc.) fueron un contendiente por un tiempo, pero creo que básicamente perdieron la guerra del lenguaje de consulta de la base de datos. Ha habido muchos otros productos de bases de datos que tenían su propio lenguaje de consulta, como Progress y Paradox y varios otros que he usado cuyos nombres no recuerdo y seguramente muchos más de los que nunca había oído hablar. Pero no creo que ningún otro competidor se acerque siquiera a obtener una participación no trivial del mercado.
Como prueba simple de que existe una diferencia entre un formato de base de datos y un lenguaje de consulta, la última versión de DBase que utilicé, hace ya muchos años, ofrecía tanto el lenguaje de consulta DBase "tradicional" como SQL, los cuales podrían usarse para acceder a los mismos datos.
Paseo lateral: no diría que SQL apesta, pero tiene muchos defectos. Con el beneficio de los años de experiencia y la visión retrospectiva que tenemos ahora, estoy seguro de que se podría diseñar un mejor lenguaje de consulta. Pero crear un mejor lenguaje de consulta y convencer a las personas para que lo utilicen son dos cosas muy diferentes. ¿Sería mejor convencer a la gente de que valía la pena aprender? La gente ha invertido muchos años de su vida en aprender a utilizar SQL de forma eficaz. Incluso si su nuevo idioma es más fácil de usar, seguramente habrá una curva de aprendizaje. ¿Y cómo migraría sus sistemas existentes de SQL al nuevo lenguaje? Etc. Se puede hacer, por supuesto, al igual que C ++, C # y Java han derrocado en gran medida a COBOL y FORTRAN. Pero se necesita una combinación de superioridad técnica y buen marketing para lograrlo.
Aún así, me ríen las personas que se apresuran a defender SQL cada vez que alguien lo critica, que insisten en que cualquier problema que tenga con SQL debe ser su propia ineptitud al usarlo y no una falla de SQL, que simplemente no debe tener. alcanzado el plano superior de las cosas necesarias para comprender su perfección, etc. Cálmate, respira hondo: estamos insultando un lenguaje informático, no a tu madre.
fuente
Eche un vistazo a LINQ to SQL ...
Lo probé hace un par de meses y nunca miré hacia atrás ...
fuente
En la década de 1980, ObjectStore proporcionaba acceso transparente a objetos. Era como un RDBMS más un ORM, excepto que sin todas esas capas de abstracción con fugas adicionales: almacenaba objetos directamente en la base de datos.
Así que esta alternativa era realmente "ningún idioma", o quizás "el idioma que ya estás usando". Escribiría código C ++ y crearía o atravesaría objetos como si fueran objetos nativos, y la base de datos se encargaría de todo según fuera necesario. Algo parecido a ActiveRecord, pero en realidad funcionó tan bien como afirman los bombardeos de marketing de ActiveRecord. :-)
(Por supuesto, no tenía la fuerza de marketing de Oracle y no tenía el costo cero de MySQL, por lo que todos lo ignoraron. Y ahora intentamos replicar eso con RDBMS y ORM, y algunas personas intentan argumentar que las tablas en realidad tienen sentido para almacenar objetos, y escribir un archivo XML gigante para decirle a su computadora cómo asignar objetos a tablas es de alguna manera una solución razonable).
fuente
El movimiento general en estos días es NoSQL; generalmente estas tecnologías son:
Personalmente, creo que SQL no tiene nada de malo siempre que se adapte a sus necesidades. SQL es expresivo y excelente para trabajar con datos estructurados.
fuente
Creo que podría estar interesado en ver Dataphor , que es un entorno de desarrollo relacional de código abierto con su propio servidor de base de datos (que habla D) y la capacidad de derivar interfaces de usuario a partir de su lenguaje de consulta.
Además, parece que Ingres todavía es compatible con QUEL y es de código abierto.
fuente
SQL funciona bien para el dominio para el que fue diseñado: tablas de datos interrelacionadas. Esto se encuentra generalmente en el procesamiento tradicional de datos comerciales. SQL no funciona tan bien cuando se intenta mantener una red compleja de objetos.
Si sus necesidades son almacenar y procesar datos relativamente tradicionales, utilice algún DBMS basado en SQL.
En respuesta a tu edición:
Si está buscando alternativas al DML de SQL para recuperar datos de almacenes de datos relacionales, nunca he oído hablar de ninguna alternativa seria a SQL.
Creo que los golpes que recibe SQL no son tanto contra el lenguaje como contra los principios de almacenamiento de datos subyacentes en los que se basa el lenguaje. La gente a menudo confunde el lenguaje SQL con el modelo de datos relacionales en el que se construyen los RDBMS.
fuente
Las bases de datos relacionales no son el único tipo de bases de datos que existen. Debo decir una palabra sobre las bases de datos de objetos, ya que no lo he visto en las respuestas de otros. Tenía algo de experiencia con el marco de Python de Zope que usa ZODB para la persistencia de objetos en lugar de RDBMS (bueno, teóricamente es posible reemplazar ZODB por otra base de datos dentro de Zope, pero la última vez que verifiqué no logré que funcionara, así que puedo No seas positivo sobre eso).
La mentalidad de ZODB es realmente diferente, más como la programación de objetos que resultaría ser persistente.
ORM puede verse como una especie de lenguaje
En cierto modo, creo que el modelo de base de datos de objetos es de lo que se trata ORM: acceder a datos persistentes a través de su modelo de objetos habitual. Es una especie de lenguaje y está ganando cuota de mercado, pero por ahora no lo vemos como un lenguaje sino como una capa de abstracción. Sin embargo, creo que sería mucho más eficiente usar un ORM sobre una base de datos de objetos que sobre SQL (en otras palabras, el rendimiento de los ORM que usé usando alguna base de datos SQL ya que las capas base apestaban).
fuente
Hay muchas implementaciones de SQL (SQL Server, mysql, Oracle, etc.), pero no hay otro lenguaje que tenga el mismo propósito en el sentido de ser un lenguaje de propósito general diseñado para el almacenamiento y recuperación de datos relacionales .
Hay bases de datos de objetos como db4o , y hay bases de datos noSQL similares que se refieren a casi cualquier mecanismo de almacenamiento de datos que no dependa de SQL, pero más comúnmente productos de código abierto como Cassandra, basados libremente en el concepto Bigtable de Google .
También hay una serie de productos de bases de datos de propósito especial como CDF, pero probablemente no tenga que preocuparse por ellos; si lo necesita, lo sabrá.
Ninguno de estos es equivalente a SQL.
Eso no significa que sean "mejores" o "peores", simplemente no son iguales. Dennis Forbes escribió una gran publicación recientemente desglosando una serie de afirmaciones extrañas que surgen contra SQL. Él sostiene (y estoy de acuerdo) que estas quejas se originan en gran parte de personas y tiendas que han elegido la herramienta incorrecta para el trabajo en primer lugar, o no están usando su DBMS SQL correctamente (ni siquiera me sorprende cuando ver otra base de datos SQL donde cada columna es un
varchar(50)y no hay un solo índice o clave, en ninguna parte).Si está implementando otro sitio de redes sociales y no está demasiado preocupado por los principios de ACID , comience a buscar productos como db4o. Si está desarrollando un sistema de negocio de misión crítica, sin embargo, muy altamente recomiendo que pensar dos veces antes de unirse a la "chupa SQL" coro. Primero investigue, descubra qué características pueden y no pueden admitir los distintos productos.
Editar: estaba ocupado escribiendo mi respuesta y no recibí la actualización de la pregunta en unos minutos. Dicho esto, SQL es esencialmente inseparable del propio DBMS. Si ejecuta un producto de base de datos SQL, entonces accede a él con SQL, punto.
Quizás esté buscando abstracciones sobre la sintaxis; Linq to SQL, Entity Framework, Hibernate / NHibernate, SubSonic y una serie de otras herramientas ORM proporcionan su propia sintaxis similar a SQL que no es del todo SQL. Todos estos se "compilan" en SQL. Si ejecuta SQL Server, también puede escribir Funciones / Procedimientos / Disparadores CLR, lo que le permite escribir código en cualquier lenguaje .NET que se ejecutará dentro de la base de datos; sin embargo, esto no es realmente un sustituto de SQL, sino más una extensión.
No conozco ningún "lenguaje" completo que pueda superponerse a una base de datos SQL; a menos que cambie a un producto de base de datos diferente, eventualmente verá SQL en la tubería.
fuente
SQL es de facto.
Los frameworks que intentan proteger a los desarrolladores han creado finalmente su propio lenguaje específico (me viene a la mente Hibernate HQL).
SQL resuelve un problema bastante bien. No es más difícil de aprender que un lenguaje de programación de alto nivel. Si ya conoce un lenguaje funcional, comprender SQL es muy sencillo.
Teniendo en cuenta que los principales proveedores de bases de datos que ofrecen bases de datos de última generación (Oracle y SQL Server) admiten SQL y han invertido años en motores de optimización, etc. y en todos los programas líderes de software de modelado de datos y software de gestión de cambios en SQL, diría que es el apuesta más segura.
Además, una base de datos es más que solo consultas. Hay escalabilidad, respaldo y recuperación, minería de datos. Los grandes proveedores admiten muchas cosas que incluso los nuevos motores de "caché" ni siquiera consideran.
fuente
Los problemas con SQL me han motivado a crear un borrador de lenguaje de consulta llamado SMEQL en la wiki de Portland Pattern Repository . Comentarios Bienvenidos. Toma prestadas ideas de la programación funcional y del lenguaje experimental Business System 12 de IBM. (Originalmente lo llamé TQL, pero luego descubrí que ese nombre fue tomado).
fuente
Dentro del mundo .NET, aunque todavía tiene una sensación similar a SQL, LINQ-to-SQL le permitirá tener una buena combinación de procesamiento de datos SQL y .NET en memoria. También simplifica gran parte de la plomería de datos de nivel inferior que nadie realmente quiere hacer.
Si desea ver un tipo de base de datos con una mentalidad completamente diferente, eche un vistazo a CouchDB . "Mejor" es obviamente un requisito relativo y este tipo de base de datos sin relación es "Mejor" pero solo en ciertos escenarios.
fuente
El lenguaje SQL es muy poderoso y los sistemas de administración de bases de datos relacionales han sido y siguen siendo un gran éxito. Pero hay una clase de aplicación que requiere una gran escalabilidad y disponibilidad, pero no necesariamente un alto grado de consistencia de datos (lo que importa es la consistencia eventual). Una variedad de sistemas obtienen un mejor rendimiento y escalamiento que un RDBMS al aliviar la necesidad de transacciones que cumplan con ACID. Estos han sido llamados "NoSQL", pero como otros señalan, este es un nombre inapropiado: que quizás deberían llamarse bases de datos NoACID.
Michael Stonebraker cubre esto en La discusión sobre "NoSQL" no tiene nada que ver con SQL .
fuente