Pourquoi SQL est-il le seul langage de requête de base de données?
Pour la programmation à usage général, il existe littéralement des centaines de langages de programmation. Mais pour interagir/interroger les bases de données, pourquoi SQL est-il à peu près le seul langage utilisé?
En plus de la réponse de Basile, veuillez également reconnaître que SQL n'est pas un langage comme vous le pensez d'un langage orienté objet ou d'un langage procédural. À bien des égards, la norme ANSI SQL ressemble plus à un protocole ou à une série d'instructions généralement acceptées basées sur les principes mathématiques de théorie des ensembles , logique des prédicats et algèbre relationnelle .
Mais la façon dont les développeurs RDBMS implémentent ces normes varient considérablement d'un logiciel propriétaire à l'autre, de manière à presque classer chaque implémentation individuelle comme un langage qui lui est propre.
Par exemple, Oracle SQL est assez différent de Microsoft SQL Server SQL qui est différent de MySQL , etc. En plus de cela, chaque entreprise implémente ses propres fonctions uniques, moteur de base de données et (dans certains cas) procédural langages en plus des instructions standard ANSI SQL standard. Certains choisissent même d'abandonner la norme à certains moments au profit de leur propre mise en œuvre personnelle.
L'histoire de ce mariage de SQL avec le modèle relationnel est principalement due au fait que la technologie et le langage ont été développés côte à côte dans les années 1970 par EF Codd , Donald D. Chamberlin et Raymond F Boyce. Il y a quelques articles assez décents sur Wikipédia autour du sujet si vous avez la possibilité de lire à ce sujet.
Le premier SQL est principalement destiné aux bases de données relationnelles . Et il a plusieurs variantes ou dialectes.
Les bases de données non relationnelles ont donc d'autres langages de requête. Lisez à propos de NoSQL . Regardez MongoDB par exemple. Voir aussi Query language wikipage listant d'autres langages de requête.
SQL n'est pas un "langage" en soi, autant qu'il est un standard pour créer un langage. Voir The SQL Timeline pour référence. Plusieurs parties ont mis en œuvre des langages de requête de base de données spécifiques basés sur la norme, qui varient dans la mesure dans laquelle la norme est respectée.
En ce sens, il est faux de dire que SQL est le seul langage de requête de base de données, car il n'existe pas de "langage SQL"; vous disposez plutôt de plusieurs implémentations de langage, telles que Transact-SQL (par exemple, tel qu'utilisé par Microsoft SQL Server), MySQL, PostgreSQL, Oracle SQL, etc. étant conçu pour le domaine d'un moteur de base de données relationnelle spécifique.
Comme Basile Starynkevitch correctement souligné , il existe également plusieurs langages de base de données "NoSQL" qui peuvent être implémentés via des API qui peuvent être utilisées par la plupart des langages de programmation traditionnels.
Bon vieux oncle Bob
Je vous encourage à considérer ce que Robert "Oncle Bob" Martin a à dire sur les bases de données . Je le trouve intéressant, en ce qui concerne certaines considérations qu'il discute concernant SQL et NoSQL.
TLDR
La popularité de SQL a été influencée par des sociétés, la communauté open source, des piles technologiques comme LAMPE et les limitations de stockage physique des disques durs. Depuis 2016, vos trois premiers systèmes de base de données sont tous basés sur SQL (Oracle 12c, Microsoft SQL Server et MySQL). Il a également été souligné dans les commentaires ci-dessous que SQL a été une norme approuvée à la fois pour ANSI , (American National Standards Institute) et Organisation internationale de normalisation ISO pendant des décennies, ce qui a de vastes répercussions sur sa prévisibilité et sa qualité - une considération commerciale très importante pour de nombreuses entreprises.
Considérations sur le stockage physique
Jusqu'à l'apparition généralisée des SSD et du cloud computing au cours de la dernière décennie, SQL était le leader prédominant des langages de bases de données; avec ces nouvelles technologies, cependant, une nouvelle évolution des langages de bases de données apparaît également. Il y a eu quelques articles discutant du combler l'écart de prix et augmenter à la fois la popularité et l'accessibilité des SSD sur les disques durs. Il existe un excellent site Web pour classement des technologies de base de données disponible, qui pourrait vous intéresser. Vous pouvez voir que les bases de données SQL et relationnelles ont toujours une emprise solide, mais les alternatives NoSQL telles que MongoDB sont rampant également .
Les Goliaths
SQL a gagné en popularité au cours des dernières décennies depuis son décollage au milieu des années 80. Aujourd'hui, la nature "concrète" de sa popularité peut être considérée en ce qui concerne deux des sociétés les plus influentes de la planète, dont les produits d'entreprise reposent largement sur des solutions tournant autour du langage SQL. Ces deux sociétés sont: Oracle et Microsoft. D'innombrables petites, moyennes et grandes entreprises utilisent des produits Oracle et Microsoft, tels que Oracle 12c, Microsoft SQL Server et MySQL . Il est également important de noter l'impact de la communauté open source, qui au cours des 20 dernières années environ, où il était très courant de voir de nombreux développeurs utiliser PHP et MySQL ensemble à travers des choses comme la LAMPE, MAMP , XAMPP , et WAMP piles.
Les deux sociétés, Microsoft et Oracle, sont des goliaths logiciels, et les langages de programmation OOP qu'ils fournissent) sont deux des plus populaires: Java et C #.
Java, acquis par Oracle il y a environ 6 ans, est l'un des langages de programmation les plus populaires au monde. Par conséquent, Oracle a tout intérêt à s'assurer que son langage de programmation est utilisé en tandem avec MySQL, qui est la source d'un revenu très élevé pour l'entreprise.
C #, appartenant à Microsoft, s'intègre très bien avec SQL Server via les différentes offres de bases de données de Microsoft, telles que le stockage cloud dans Azure ainsi que les installations locales de Windows Server, qui s'exécutent généralement avec une instance de SQL Server Management Studio .
D'autres langages populaires comme PHP s'intègrent aussi bien avec MySQL, en raison de la nature open source de ces langages. Le LAMP (Linux, Apache, MySQL et PHP), ainsi que MAMP, XAMP et WAMP, ont également fourni une incursion dans un mélange de technologies open source prêtes à l'emploi qui étaient à la mode il y a environ 20 ans (et qui sont toujours très populaires à ce jour).
La communauté open-source autour de ces langages (en particulier SQL) est énorme, il est donc assez facile de trouver du support.
La langue elle-même est également très facile à comprendre et à lire, étant donné qu'elle est très proche de la façon dont vous structureriez une phrase logique en anglais (s'il y a une telle chose!).
Un peu de concurrence
Cependant, alors que SQL et d'autres bases de données relationnelles sont solides, d'autres technologies alternatives de stockage de documents, comme NoSQL, MongoDB , CouchDB et les implémentations NoSQL de Microsoft deviennent de plus en plus populaires ainsi .
Avancées technologiques physiques
Une partie de cette augmentation de l'utilisation des plates-formes de type NoSQL peut être due aux technologies matérielles physiques qui se sont installées sur le marché. Alors que les SSD et les disques durs deviennent plus comparables en prix , stockant les données sous la forme de gros documents JSON et dans le référentiel et systèmes de stockage d'objets , tels que Amazon Stockage S devient relativement moins cher, physiquement et financièrement, que vous envisagiez de le stocker sur votre propre disque dur localement ou quelque part dans le cloud.
Offres Cloud
Les offres cloud deviennent de moins en moins chères de jour en jour, et 1 To de stockage dans le cloud est pratiquement très bon marché aussi . J'ai personnellement 1 To de stockage Google Drive pour 1,99 $ par mois (environ 25 $ par an).
Quelques conclusions ...
L'espace de stockage (physiquement) était auparavant un problème crucial, où de nombreuses bases de données SQL répondaient à un besoin d'un langage de données qui pourrait être utilisé pour maintenir le stockage des données aussi efficace que possible. C'est là que vous obtenez les applications de style CRUD (Créer, Lire, Mettre à jour, Supprimer). Lorsque vous stockez d'énormes quantités de données dans une base de données SQL, vous voulez éviter autant que possible la duplication grâce à un processus connu sous le nom de normalisation, qui a à voir avec la conception de la base de données de manière à avoir un mappage relationnel aussi efficace que possible . Cela aiderait la vitesse de recherche physique (également améliorée grâce à l'indexation), mais tout était centré sur une préoccupation majeure, qui était l'espace physique. Vous ne pouviez tout simplement pas vous permettre d'avoir d'énormes quantités de données en double. Sans parler de la nécessité de réplication et de sauvegarde de la base de données, pour se protéger contre des choses comme les catastrophes naturelles ou les pannes de courant, les terroristes, etc.
Les énormes entreprises avec d'énormes quantités de données de cartes de crédit ou d'informations sur la santé ne pouvaient pas se permettre de baisser pendant une minute, elles devaient donc répliquer et distribuer géographiquement leurs centres de données pour protéger les données de leurs utilisateurs. Cela était extrêmement coûteux, car chaque base de données avait besoin d'un point de terminaison physique, d'un ordinateur et d'un disque dur pour stocker la masse d'informations.
Avance rapide jusqu'à aujourd'hui, le besoin de taille physique est moins cher. Nous verrons probablement un changement de SQL au cours des prochaines années, mais il a une si grande base d'utilisateurs, et de nombreuses grandes entreprises sont si solidement ancrées, que cela prendra probablement un certain temps.
Cependant, de nouvelles industries, telles que l'infrastructure en tant que service, fournies par des entreprises comme Amazon avec leurs Amazon Web Services (AWS) - ainsi que Microsoft Azure , grands centres de données évolutifs remplis à ras bord avec des disques durs SSD haute capacité et moins gourmands en énergie, il est de plus en plus possible pour ces grandes entreprises de migrer vers des technologies plus récentes et plus efficaces. En conséquence, nous verrons probablement le changement de langage de base de données pour refléter de nouvelles limitations physiques, logiques et scientifiques.
Ce n'est pas le seul langage de requête ... Les langages de requête ont différentes variantes d'implémentation. Fondamentalement, SQL est considéré comme des normes de référence ou en interne, d'autres langages sont convertis en SQL.
Certains des langages de requête sont répertoriés ici .
Les développeurs C # utilisent très souvent le langage de requête LINQ .
C'est une très bonne question, mais vous pourriez plus généralement demander:
Pourquoi toutes les bases de données relationnelles sont-elles si remarquablement similaires?
Hormis les variantes plus petites qui viennent avec une interface graphique comme Access et Filemaker et les moteurs à utilisateur unique quelque peu spéciaux, les bases de données relationnelles partagent toutes un nombre étonnant de particularités:
- Comme cela fait déjà partie de votre question, ils utilisent tous le même langage de requête (ancien et imparfait) auquel ils ajoutent tous de nouvelles fonctionnalités. C'est le pire des deux mondes: personne n'ose innover loin de SQL, mais les dialectes ne sont toujours pas compatibles.
- Même si le schéma de base de données est également toujours défini à l'aide de ce langage (avec DDL), les bases de données ne renvoient pas le schéma actuel sous cette forme. Ils le renvoient plutôt sous la forme de diverses formes de données tabulaires. Beaucoup ont des utilitaires côté client qui peuvent ensuite reconvertir ces informations en DDL. Ce qui, bien sûr, est difficile à faire par programmation pour les mises à jour. Bizarre, mais c'est comme ça qu'ils font tous.
- Ils ne peuvent pas vous donner une vue en direct d'une requête: le jeu de résultats ainsi qu'un flux en temps réel des modifications. C'est pourquoi les applications de base de données réinterrogent tout tout le temps.
- Même s'ils prennent tous en charge le concept de contraintes, en particulier sous la forme de clés étrangères et uniques, aucun d'entre eux ne fournit au code appelant suffisamment d'informations pour que ce code appelant comprenne laquelle de ces contraintes a été violée lorsque cela se produit. C'est pourquoi les logiciels basés sur une base de données doivent toujours faire l'unicité explicite et la vérification des clés étrangères - une violation de DRY et une douleur.
- Ils sont mal à donner des informations sur la raison pour laquelle les requêtes sont lentes, c'est pourquoi les applications de base de données se bloquent généralement sans explication lorsque quelque chose de verrouillable ou coûteux se produit. Pourquoi ne puis-je pas obtenir une vue en direct du plan d'exécution avec des indicateurs de progression sur les nœuds (avec des liens vers les requêtes de verrouillage si elles se présentent)? [EDIT: Sql Server dispose désormais de "Live Query Statistics", très cool)
- Ils ont tous des index b-tree pour les choses courantes, puis ils ont tous un autre index bidimensionnel basé sur des valeurs à virgule flottante pour les applications géographiques. Mais seulement virgule flottante, et seulement deux dimensions. Ensuite, ils ont généralement une fonction de recherche en texte intégral supplémentaire. Et plus d'un support d'index supplémentaire pour les données xml réside dans les colonnes de chaînes.
- Ils ont tous une méthode pour mesurer la similitude de deux mots en anglais.
- Ils peuvent tous faire des agrégats, mais aucun d'eux ne peut conserver des valeurs partielles agrégées dans les nœuds de branche b-tree pour le faire rapidement.
- En tant qu'instance spéciale du point précédent, aucun d'entre eux ne peut rechercher efficacement un compte ligne par ligne. En particulier, les grilles de défilement communes qui chargent paresseusement la tranche de données vers laquelle un utilisateur a fait défiler ne sont jamais efficaces pour un grand nombre de lignes - sur aucun des serveurs de bases de données relationnelles. Ils doivent tous parcourir toutes les données depuis le début du jeu de résultats jusqu'à la première ligne renvoyée. Laissez cela pénétrer.
En bref, même s'ils sont tous à la fois incroyablement incroyables et indispensables pour de nombreuses tâches de stockage et de traitement de données, ils sont également tous confus et originaux d'une manière étonnamment similaire. Vous pouvez voir comment après que le premier a été écrit, tout le monde l'a copié, et au fil du temps, les gens ont ajouté juste la fonctionnalité qui était cool à l'époque et qui a ensuite été copiée pour tous les joueurs.
Ceci est très différent des plates-formes de programmation, où il existe des paradigmes très différents et même des syntaxes très différentes au sein de chaque paradigme. De nouvelles idées sont également piratées sur une langue plus ancienne, mais le plus souvent, les gens créent de nouvelles langues et plates-formes. Java était un pas en avant en 1990. .NET était un pas en avant en 2002. Un langage à peu près aussi ancien que la base de données relationnelle serait C++, et cela montre. Seulement avec les bases de données relationnelles, on a pas d'autre choix que de les utiliser.
Je sais qu'il existe des bases de données "NoSQL", mais le paradigme relationnel est toujours extrêmement important. C'est triste qu'il y ait si peu de pluralisme là-bas.