Quelles sont les bonnes alternatives à SQL (le langage) ?

Question

J'entends parfois dire que SQL est nul et que ce n'est pas un bon langage, mais je n'entends jamais vraiment parler d'alternatives à ce langage. Alors, y a-t-il d'autres bons langages qui servent le même objectif (accès aux bases de données) et qu'est-ce qui les rend meilleurs que SQL ? Existe-t-il de bonnes bases de données qui utilisent ce langage alternatif ?

EDIT : Je connais bien SQL et je l'utilise tout le temps. Je n'ai pas de problème avec lui, je suis juste intéressé par les alternatives qui peuvent exister, et pourquoi les gens les préfèrent.

Je ne recherche pas non plus d'autres types de bases de données (le mouvement NoSQL), mais simplement d'autres façons d'accéder aux bases de données.

Answer 1

Je suis tout à fait d'accord pour dire que la syntaxe de SQL est difficile à travailler, tant du point de vue de la génération automatique que du point de vue de l'analyse syntaxique, et ce n'est pas le style de langage que nous écririons aujourd'hui si nous concevions SQL pour les exigences que nous lui imposons aujourd'hui. Je ne pense pas que nous trouverions autant de mots-clés variés si nous concevions le langage aujourd'hui, je soupçonne que la syntaxe de jointure serait différente, des fonctions comme GROUP_CONCAT aurait une syntaxe plus régulière plutôt que de coller des mots-clés au milieu des parenthèses pour contrôler son comportement... créez votre propre liste d'incohérences et de redondances dans SQL que vous aimeriez/attendez voir aplanies si nous redessinions le langage aujourd'hui.

Il n'existe pas d'alternatives à SQL pour communiquer avec les bases de données relationnelles (c'est-à-dire SQL en tant que protocole), mais il existe de nombreuses alternatives à l'écriture de SQL dans vos applications. Ces alternatives ont été mises en œuvre sous la forme d'interfaces pour travailler avec des bases de données relationnelles. Voici quelques exemples d'interfaces :

• SchemeQL y CLSQL qui sont probablement les plus flexibles, en raison de leur héritage Lisp, mais ils ressemblent aussi beaucoup plus à SQL que les autres frontends.
• LINQ (dans .Net)
• ScalaQL y ScalaQuery (en Scala)
• SqlStatement , ActiveRecord et bien d'autres dans Ruby,
• HaskellDB
• ...la liste est longue pour de nombreuses autres langues.

Je pense que le thème sous-jacent aujourd'hui est que, plutôt que de remplacer SQL par un nouveau langage d'interrogation, nous créons des interfaces spécifiques à chaque langage pour dissimuler le langage SQL dans nos langages de programmation habituels, et nous traitons SQL comme le langage de base de l'entreprise. protocole pour communiquer avec les bases de données relationnelles.

Answer 2

Jetez un oeil à cette liste.

Je n'ai pas entendu parler de l'un d'eux, sauf pour Hibernate Query Language. L'avantage d'Hibernate est que les objets de la carte très facilement (presque automatiquement) à la base de données relationnelle, et le développeur n'a pas à passer beaucoup de temps à faire de conception de base de données. Découvrez le site web Hibernate pour plus d'info. Je suis sûr que d'autres carillon avec d'autres intéressant les langages de requête...

Answer 3

"J'entends parfois dire que SQL est nul et que ce n'est pas un bon langage.

SQL a plus de trente ans. Les idées sur "les caractéristiques qui font de quelque chose un "bon" langage et celles qui en font un "mauvais"" ont évolué plus rapidement que SQL lui-même.

De plus, SQL n'est pas un langage conforme aux normes actuelles de "ce qu'il faut pour être relationnel", donc SQL n'est tout simplement pas un langage relationnel.

"mais je n'entends jamais vraiment parler d'alternatives à ce système".

Je vous invite à réfléchir à la possibilité que vous essayez d'entendre seulement au mauvais endroit (c'est-à-dire exclusivement dans l'industrie commerciale des SGBD).

"Alors, y a-t-il d'autres bons langages qui servent le même objectif (accès aux bases de données) et qu'est-ce qui les rend meilleurs que SQL ?

Date&Darwen décrivent les caractéristiques auxquelles un langage moderne de manipulation de données doit se conformer dans leur "Troisième Manifeste", dont la version la plus récente est présentée dans leur livre "Databases, Types & the Relational Model" (Bases de données, types et modèle relationnel).

"Existe-t-il de bonnes bases de données qui utilisent ce langage alternatif ?

Si par "bon", vous entendez quelque chose comme "résistant à l'échelle industrielle", alors non. La solution la plus proche serait probablement Dataphor.

Le projet Rel offre une implémentation pour le langage Tutorial D défini dans "Databases, Types & The Relational Model", mais l'objectif principal actuel de Rel est d'être de nature éducative.

Mon projet SIRA_PRISE propose une implémentation pour la gestion de données "véritablement relationnelles", mais j'hésite à le qualifier également d'"implémentation d'un langage".

Et bien sûr, vous pouvez également envisager des solutions non relationnelles, comme certains l'ont proposé, mais je rejette personnellement la gestion des données non relationnelles comme étant une régression technologique de plusieurs décennies. Cela ne vaut pas la peine d'y réfléchir.

Oh, et à propos, un système logiciel utilisé pour gérer des bases de données n'est pas "une base de données", mais "un système de gestion de base de données", "SGBD" en abrégé. Tout comme une photographie n'est pas la même chose qu'un appareil photo, et si vous parlez d'appareils photo et que vous voulez éviter toute confusion, vous devriez utiliser le mot "appareil photo" au lieu de "photographie".

Answer 4

Peut-être pensez-vous à la critique que C. Date et ses amis ont formulée à l'encontre des bases de données relationnelles existantes et du langage SQL ; ils affirment que les systèmes et le langage ne sont pas 100 % relationnels et qu'ils devraient l'être. Je ne vois pas vraiment de problème à ce niveau ; pour autant que je sache, vous pouvez avoir un système 100% relationnel, si vous le souhaitez, simplement en disciplinant la façon dont vous utilisez SQL.

Personnellement, je me heurte toujours au manque de puissance expressive que SQL hérite de sa base théorique, l'algèbre relationnelle. L'un des problèmes est l'absence de support pour l'utilisation de l'ordre des domaines, que vous rencontrez lorsque vous travaillez avec des données marquées par des dates, des horodatages, etc. J'ai essayé une fois de réaliser une application de reporting entièrement en SQL simple sur une base de données remplie d'horodatages et ce n'était tout simplement pas faisable. Un autre problème est l'absence de support pour la traversée de chemins : la plupart de mes données ressemblent à des graphes dirigés dans lesquels je dois parcourir des chemins, et SQL ne peut pas le faire. (Il manque la "fermeture transitive". SQL-1999 peut le faire avec des "sous-requêtes récursives", mais je ne les ai pas encore vues à l'œuvre. Il y a aussi diverses astuces pour permettre à SQL de le faire, mais elles sont laides). Ces problèmes sont également abordés dans certains écrits de Date.

Récemment, on m'a indiqué .QL qui semble bien résoudre le problème de la fermeture transitive, mais je ne sais pas s'il peut résoudre le problème des domaines ordonnés.

Answer 5

Jetez un coup d'œil à LINQ to SQL ...

J'ai essayé il y a quelques mois et je n'ai jamais regardé en arrière....