Quelles sont les bonnes alternatives à SQL (le langage)? [fermé]

J'entends parfois des choses sur la façon dont SQL est nul et ce n'est pas un bon langage, mais je n'entends jamais vraiment parler d'alternatives. Alors, existe-t-il d'autres bons langages qui servent le même objectif (accès à la base de données) et qu'est-ce qui les rend meilleurs que SQL? Existe-t-il de bonnes bases de données utilisant cette langue alternative?

EDIT: Je connais SQL et je l'utilise tout le temps. Je n'ai pas de problème avec ça, je suis juste intéressé par toutes les alternatives qui pourraient exister, et pourquoi les gens les aiment mieux.

Je ne cherche pas non plus d'autres types de bases de données (le mouvement NoSQL), juste différentes façons d'accéder aux bases de données.

Je conviens certainement que la syntaxe de SQL est difficile à utiliser, à la fois du point de vue de sa génération automatique et du point de vue de son analyse, et ce n'est pas le style de langage que nous écririons aujourd'hui si nous concevions SQL pour les demandes que nous imposons dessus 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_CONCATauraient une syntaxe plus régulière plutôt que de coller plus de 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 / espérez voir aplanir si nous avons repensé le langage aujourd'hui.

Il n'y a pas d'alternative à SQL pour parler aux 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é implémentées sous la forme d'interfaces pour travailler avec des bases de données relationnelles. Voici quelques exemples de frontend:

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

Je pense que le thème sous-jacent aujourd'hui est qu'au lieu de remplacer SQL par un nouveau langage de requête, nous créons plutôt des interfaces spécifiques au langage pour masquer le SQL dans nos langages de programmation quotidiens habituels, et traitons SQL comme le protocole pour parler aux relations relationnelles. bases de données.

Jetez un œil à cette liste.

Le langage de requête Hibernate est probablement le plus courant. L'avantage d'Hibernate est que les objets sont mappés très facilement (presque automatiquement) à la base de données relationnelle, et le développeur n'a pas à passer beaucoup de temps à concevoir la base de données. Consultez le site Web Hibernate pour plus d'informations. Je suis sûr que d'autres vont intervenir avec d'autres langages de requête intéressants ...

Bien sûr, il y a beaucoup de choses NoSQL là-bas, mais vous mentionnez spécifiquement que cela ne vous intéresse pas.

"J'entends parfois des choses sur la façon dont SQL est nul et ce n'est pas un bon langage"

SQL a plus de trente ans. Les connaissances sur «quelles fonctionnalités font de quelque chose un 'bon' langage et lesquelles en font un 'mauvais' langage» 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 pour démarrer.

"mais je n'entends jamais vraiment parler d'alternatives."

Je vous invite à réfléchir à la possibilité que vous n'essayez d'entendre que dans les mauvais endroits (c'est-à-dire exclusivement dans l'industrie du SGBD commercial).

"Alors, existe-t-il d'autres bons langages qui servent le même objectif (accès à la base 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 énoncée dans leur livre «Bases de données, types et modèle relationnel».

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

Si par «bien», vous entendez quelque chose comme «force industrielle», alors non. La chose la plus proche disponible serait probablement Dataphor.

Le projet Rel propose une implémentation du langage Tutorial D défini dans "Bases de données, types et modèle relationnel", mais l'objectif principal actuel de Rel est d'être de nature éducative.

Mon projet SIRA_PRISE propose une implémentation pour une gestion de données "vraiment relationnelle", mais j'hésite à l'appeler aussi "une implémentation d'un langage".

Et bien sûr, vous pouvez également vous pencher sur des éléments non relationnels, comme certains l'ont proposé, mais je rejette personnellement la gestion des données non relationnelles comme plusieurs décennies de régression technologique. Cela ne vaut pas la peine d'être considéré.

Oh, et en passant, un système logiciel qui est 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" pour faire court. 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 approprié «appareils photo» au lieu de «photographie».

Peut-être pensez-vous à la critique que C. Date et ses amis ont lancée contre les bases de données relationnelles existantes et SQL; ils disent que les systèmes et le langage ne sont pas à 100% relationnels et devraient l'être. Je ne vois pas vraiment de problème ici; pour autant que je sache, vous pouvez avoir un système 100% relationnel, si vous le souhaitez, simplement en disciplinant la manière dont vous utilisez SQL.

Ce que je n'arrête pas de rencontrer personnellement, c'est le manque de pouvoir expressif que SQL hérite de sa base théorique, l'algèbre relationnelle. Un problème est le manque de prise en charge de l'utilisation de l'ordre de domaine, que vous rencontrez lorsque vous travaillez avec des données marquées par des dates, des horodatages, etc. Une fois, j'ai essayé de faire une application de reporting entièrement en SQL clair sur une base de données pleine d'horodatages et ce n'était tout simplement pas faisable. Un autre est le manque de support pour la traversée de chemin: la plupart de mes données ressemblent à des graphiques dirigés dans lesquels j'ai besoin de traverser les chemins, et SQL ne peut pas le faire. (Il manque une "fermeture transitive". SQL-1999 peut le faire avec des "sous-requêtes récursives" mais je ne les ai pas encore vues en utilisation réelle. Il existe également divers hacks pour faire face à SQL mais ils sont laids.) Ces problèmes sont également discuté par certains des écrits de Date, d'ailleurs.

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

Réponse directe: je ne pense pas qu'il y ait de prétendant sérieux là-bas. DBase et ses imitateurs (Foxpro, Codebase, etc.) étaient un concurrent pendant un certain temps, mais je pense qu'ils ont fondamentalement perdu la guerre du langage des requêtes de base de données. Il y a eu beaucoup d'autres produits de base de données qui avaient leur propre langage de requête, comme Progress et Paradox et plusieurs autres que j'ai utilisés dont je ne me souviens pas et sûrement beaucoup d'autres dont je n'ai jamais entendu parler. Mais je ne pense pas qu'aucun autre concurrent ne soit venu près d'obtenir une part non négligeable du marché.

Preuve simple qu'il existe une différence entre un format de base de données et un langage de requête, la dernière version de DBase que j'ai utilisée - il y a de nombreuses années maintenant - offrait à la fois le langage de requête DBase «traditionnel» et SQL, qui pouvaient tous deux être utilisés pour accéder aux mêmes données.

Côté divagation: je ne dirais pas que SQL est nul, mais il a de nombreux défauts. Avec le bénéfice des années d'expérience et du recul que nous avons maintenant, je suis sûr que l'on pourrait concevoir un meilleur langage de requête. Mais créer un meilleur langage de requête et convaincre les gens de l'utiliser sont deux choses très différentes. Serait-il assez préférable de convaincre les gens que cela valait la peine d'apprendre. Les gens ont investi de nombreuses années de leur vie pour apprendre à utiliser SQL efficacement. Même si votre nouvelle langue est plus facile à utiliser, il y aura sûrement une courbe d'apprentissage. Et comment migreriez-vous vos systèmes existants de SQL vers le nouveau langage? Etc. Cela peut être fait, bien sûr, tout comme C ++, C # et Java ont largement renversé COBOL et FORTRAN. Mais il faut une combinaison de supériorité technique et de bon marketing pour y parvenir.

Pourtant, je reçois un rire des gens qui se précipitent pour défendre SQL chaque fois que quelqu'un le critique, qui insistent sur le fait que tout problème que vous rencontrez avec SQL doit être votre propre inaptitude à l'utiliser et non une faute de SQL, que vous ne devez tout simplement pas avoir atteint le niveau supérieur du trucage nécessaire pour comprendre sa perfection, etc. Calmez-vous, prenez une profonde respiration: Nous sommes en train d'insulter un langage informatique, pas votre mère.

Jetez un œil à LINQ to SQL ...

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

Dans les années 80, ObjectStore offrait un accès transparent aux objets. C'était un peu comme un SGBDR plus un ORM, sauf sans toutes ces couches d'abstraction supplémentaires qui fuyaient: il stockait les objets directement dans la base de données.

Donc, cette alternative était vraiment "pas de langue du tout", ou peut-être "la langue que vous utilisez déjà". Vous écrivez du code C ++ et créez ou parcourez des objets comme s'il s'agissait d'objets natifs, et la base de données s'occupait de tout si nécessaire. Un peu comme ActiveRecord, mais cela a fonctionné aussi bien que l'affirmation des blitz marketing d'ActiveRecord. :-)

(Bien sûr, il n'avait pas la puissance marketing d'Oracle, et il n'avait pas le coût zéro de MySQL, donc tout le monde l'a ignoré. Et maintenant nous essayons de reproduire cela avec les SGBDR et les ORM, et certaines personnes essaient de faire valoir que les tables est logique pour stocker des objets, et que l'écriture d'un fichier XML géant pour indiquer à votre ordinateur comment mapper des objets vers des tables est en quelque sorte une solution raisonnable.)

Le mouvement général de nos jours est NoSQL; généralement ces technologies sont:

• Des "hashtables" distribués qui stockent les données sous forme de paires clé / valeur
• Bases de données orientées document

Personnellement, je pense qu'il n'y a rien de mal avec SQL tant qu'il répond à vos besoins. SQL est expressif et idéal pour travailler avec des données structurées.

Je pense que vous pourriez être intéressé par Dataphor , qui est un environnement de développement relationnel open-source avec son propre serveur de base de données (qui parle D), et la possibilité de dériver des interfaces utilisateur à partir de son langage de requête.

En outre, il semble qu'Ingres supporte toujours QUEL, et qu'il est open source.

SQL fonctionne très bien pour le domaine pour lequel il a été conçu - des tables de données interdépendantes. Cela se retrouve généralement dans le traitement traditionnel des données commerciales. SQL ne fonctionne pas très bien lorsque vous essayez de conserver un réseau complexe d'objets.

Si vous avez besoin de stocker et de traiter des données relativement traditionnelles, utilisez un SGBD basé sur SQL.

En réponse à votre modification:

Si vous recherchez des alternatives au DML SQL pour récupérer des données à partir de magasins de données relationnelles, je n'ai jamais entendu parler d'alternative sérieuse à SQL.

Les coups que reçoit SQL ne sont pas, je pense, autant contre le langage que contre les principes de stockage de données sous-jacents sur lesquels le langage est basé. Les gens confondent souvent le langage SQL avec le modèle de données relationnel sur lequel les SGBDR sont construits.

Les bases de données relationnelles ne sont pas le seul type de bases de données disponibles. Je devrais dire un mot sur les bases de données d'objets car je ne l'ai pas vu dans les réponses des autres. J'ai eu une certaine expérience avec le framework Zope python qui utilise ZODB pour la persistance des objets au lieu du SGBDR (enfin, il est théoriquement possible de remplacer ZODB par une autre base de données dans zope mais la dernière fois que j'ai vérifié, je n'ai pas réussi à le faire fonctionner, donc je peux ne soyez pas positif à ce sujet).

L'état d'esprit ZODB est vraiment différent, plus comme la programmation objet qui se trouverait persistante.

ORM peut être vu comme une sorte de langage

D'une certaine manière, je crois que le modèle de base de données d'objets est ce que l'ORM est: accéder aux données persistantes via votre modèle d'objet habituel. C'est une sorte de langage et il gagne des parts de marché, mais pour l'instant nous ne le voyons pas comme un langage mais comme une couche d'abstraction. Cependant, je pense qu'il serait beaucoup plus efficace d'utiliser un ORM sur une base de données d'objets que sur SQL (en d'autres termes, les performances des ORM que j'ai utilisées en utilisant une base de données SQL comme couches de base étaient nulles).

Il existe de nombreuses implémentations de SQL (SQL Server, mysql, Oracle, etc.), mais il n'y a pas d'autre langage qui sert le même objectif dans le sens d'être un langage à usage général conçu pour le stockage et la récupération de données relationnelles .

Il existe des bases de données d'objets telles que db4o , et il existe des bases de données similaires dites noSQL qui se réfèrent à à peu près n'importe quel mécanisme de stockage de données qui ne repose pas sur SQL, mais le plus souvent des produits open-source comme Cassandra basés vaguement sur le concept Bigtable de Google .

Il existe également un certain nombre de produits de base de données à usage spécial comme CDF, mais vous n'avez probablement pas à vous en soucier - si vous en avez besoin, vous le saurez.

Aucun de ceux-ci n'est équivalent à SQL.

Cela ne veut pas dire qu'ils sont «meilleurs» ou «pires» - ils ne sont tout simplement pas les mêmes. Dennis Forbes a récemment écrit un excellent article décomposant un certain nombre de prétentions étranges contre SQL. Il soutient (et je suis d'accord) que ces plaintes proviennent en grande partie de personnes et de magasins qui ont soit choisi le mauvais outil pour le travail en premier lieu, soit n'utilisent pas correctement leur SGBD SQL (je ne suis même plus surpris quand je voir une autre base de données SQL où chaque colonne est un varchar(50)et il n'y a pas un seul index ou clé, nulle part).

Si vous implémentez un autre site de réseautage social et que vous n'êtes pas trop préoccupé par les principes ACID , commencez par tous les moyens à vous pencher sur des produits tels que db4o. Cependant, si vous développez un système d'entreprise critique, je vous recommande vivement de réfléchir à deux fois avant de rejoindre le chœur «SQL sucks». Faites d'abord la recherche, découvrez quelles fonctionnalités les différents produits peuvent et ne peuvent pas prendre en charge.

Modifier - J'étais occupé à rédiger ma réponse et je n'ai pas reçu la mise à jour de la question après quelques minutes. Cela dit, SQL est essentiellement inséparable du SGBD lui-même. Si vous exécutez un produit de base de données SQL, vous y accédez avec SQL, point final.

Vous recherchez peut-être des abstractions sur la syntaxe; Linq to SQL, Entity Framework, Hibernate / NHibernate, SubSonic et une foule d'autres outils ORM fournissent tous leur propre syntaxe de type SQL qui n'est pas tout à fait SQL. Tous ces "compilent" en SQL. Si vous exécutez SQL Server, vous pouvez également écrire des fonctions / procédures / déclencheurs CLR, ce qui vous permet d'écrire du code dans n'importe quel langage .NET qui s'exécutera dans la base de données; cependant, ce n'est pas vraiment un substitut à SQL, mais plutôt une extension de celui-ci.

Je ne connais aucun "langage" complet que vous pouvez superposer au-dessus d'une base de données SQL; à moins de passer à un autre produit de base de données, vous allez éventuellement voir SQL sur le canal.

SQL est de facto.

Les frameworks qui tentent d'en protéger les développeurs ont finalement créé leur propre langage spécifique (Hibernate HQL vient à l'esprit).

SQL résout assez bien un problème. Ce n'est pas plus difficile à apprendre qu'un langage de programmation de haut niveau. Si vous connaissez déjà un langage fonctionnel, il est facile de comprendre SQL.

Étant donné que les principaux fournisseurs de bases de données fournissant des bases de données de pointe (Oracle et SQL Server) prennent en charge SQL et ont investi des années dans des moteurs d'optimisation, etc. pari le plus sûr.

En outre, une base de données ne se résume pas à des requêtes. Il y a l'évolutivité, la sauvegarde et la restauration, l'exploration de données. Les grands fournisseurs supportent beaucoup de choses que même les nouveaux moteurs de "cache" ne prennent même pas en compte.

Des problèmes avec SQL m'ont motivé à préparer un brouillon de langage de requête appelé SMEQL sur le wiki Portland Pattern Repository . Commentaires Bienvenue. Il emprunte des idées à la programmation fonctionnelle et au langage expérimental Business System 12 d'IBM. (Je l'ai initialement appelé TQL, mais j'ai découvert plus tard que ce nom avait été pris.)

Dans le monde .NET, bien qu'il ait toujours une sensation SQL-esque, LINQ-to-SQL vous permettra d'avoir un bon mélange de traitement SQL et .NET en mémoire de vos données. Cela simplifie également une grande partie de la plomberie de données de niveau inférieur que personne ne veut vraiment faire.

Si vous voulez voir un type de base de données d'un état d'esprit complètement différent, jetez un œil à CouchDB . «Mieux» est évidemment une exigence relative et ce type de base de données sans relation est «Mieux» mais seulement dans certains scénarios.

SQL le langage est très puissant, et les systèmes de gestion de bases de données relationnelles ont été et sont encore un énorme succès. Mais il existe une classe d'applications qui nécessite une évolutivité et une disponibilité très élevées, mais pas nécessairement un degré élevé de cohérence des données (la cohérence éventuelle est ce qui compte). Une variété de systèmes obtiennent de meilleures performances et une meilleure évolutivité qu'un SGBDR en allégeant le besoin de transactions entièrement conformes à ACID. Celles-ci ont été nommées "NoSQL", mais comme d'autres le soulignent, c'est un abus de langage: qu'elles devraient peut-être être appelées bases de données NoACID.

Michael Stonebraker en parle dans La discussion "NoSQL" n'a rien à voir avec SQL .