Pourquoi SQL est-il connu comme un langage relationnel / fonctionnel?

Nous apprenons que la plupart des langues sont classées comme l'une des deux, "basées sur les relations" ou "de haut niveau". Je n'ai jamais utilisé SQL auparavant, mais à la lecture de sa syntaxe, cela ressemble plus à la syntaxe impérative / de haut niveau qu'à la fonctionnelle / relationnelle (Lisp, Haskell) ??

Ou il se pourrait que mon interprétation des notes de cours de mon professeur soit erronée ... mais il répertorie définitivement SQL comme l'un des langages basés sur les relations (par opposition au niveau élevé), et il associe relation basée à fonctionnelle ... ou peut-être que je ne comprends pas pourquoi le fait que SQL traite des bases de données relationnelles rend un langage fonctionnel comme il devrait être mis en œuvre (et pourquoi «relationnel» équivaut à «fonctionnel» lors de la catégorisation des langages de programmation?)

Merci :)

Nous apprenons que la plupart des langues sont classées comme l'une des deux, "basées sur les relations" ou "de haut niveau".

Ces concepts sont orthogonaux. "Basé sur les relations" signifie que la sémantique du langage est basée sur le concept d'une relation, c'est-à-dire une association plusieurs-à-plusieurs entre deux ensembles (les relations sont le fondement mathématique derrière les tables SQL). "De haut niveau" signifie que le langage contient beaucoup d'abstractions qui cachent une grande partie des détails techniques sous-jacents (tels que les emplacements de mémoire, les registres du processeur, l'accès au disque, les opérations au niveau du bit, etc.). SQL est certainement basé sur les relations, car son objectif principal est de décrire les données relationnelles et les opérations qui s'y rapportent. SQL est également un niveau assez élevé; il ne fournit aucun moyen d'accéder directement aux octets sur le disque, et il ne vous donne aucun détail sur la façon dont il stocke ses données (du moins, le SQL standard ne le fait pas;

En fait, il existe de nombreux autres axes le long desquels les langages de programmation (et de données) peuvent être classés; une déclaration particulièrement intéressante est déclarative et impérative . Langages déclaratifs décrivent ce que quelque chose est ; les langues impératives décrivent comment faire quelque chose. La partie de SQL DDL est la plupart du temps déclarative, malgré les mots - clés impératifs prospectifs ( » CREATE TABLE», « DROP DATABASE», etc.), et même la partie de manipulation de données ( SELECT, UPDATE, INSERT, DELETE) est encore assez déclarative. Une propriété très intéressante de SQL est qu'il n'est pas Turing complet: vous ne pouvez pas écrire une boucle illimitée en SQL ANSI standard standard.

La programmation fonctionnelle s'articule autour de quelques idées fondamentales:

• les fonctions sont des citoyens de première classe (c'est-à-dire qu'elles peuvent être utilisées comme valeurs, comme entrées pour d'autres fonctions et comme sortie d'autres fonctions)
• fonctions d'ordre supérieur (fonctions qui opèrent sur des fonctions ou fonctions qui renvoient des fonctions)
• pureté (une fonction pure est une fonction qui n'a pas d'effets secondaires; une fonction pure ne peut pas faire d'E / S, elle ne peut ni lire ni modifier aucun état global, et elle ne peut pas prendre d'arguments de référence non const. Les fonctions pures sont particulièrement intéressantes car elles toujours produire la même sortie pour les mêmes entrées)

SQL ne tourne certainement pas autour des fonctions comme outil principal pour modéliser les choses, mais il embrasse quelque peu l'idée de pureté - la même requête exécutée sur la même base de données donnera le même résultat, à chaque fois (sauf pour la commande). Appeler SQL un langage «fonctionnel» est un peu exagéré grâce à l'OMI.

SQL n'est pas impératif car le processus de résolution des requêtes et des relations n'est pas défini par le programmeur, mais plutôt par le compilateur / optimiseur / interprète. SQL est un langage déclaratif - En SQL, vous déclarez des relations. Cela crée une structure de données (qui n'est pas définie physiquement avec le langage mais par son implémentation) à l'aide d'insertions, de mises à jour et de suppressions.

L'utilisation des relations se fait ensuite à l'aide de requêtes (instructions SELECT), qui sont fonctionnelles en ce qu'elles n'ont pas d'effets secondaires.

Le tout est enroulé autour du modèle relationnel .

SQL n'est pas vraiment autant un langage fonctionnel qu'il est déclaratif. Les langages fonctionnels, en général, mettent l'accent sur le style déclaratif plutôt que sur l'impératif pour minimiser les effets secondaires. Cela pourrait conduire certaines personnes à qualifier SQL de fonctionnel, mais ce n'est pas exact. C'est déclaratif avec des éléments procéduraux.

Est-il possible que vos notes soient brouillées?

Je n'ai jamais entendu parler de langages de programmation divisés entre "basé sur les relations" et "haut niveau". Le niveau bas / haut est généralement utilisé pour distinguer l'assembleur et le C des langages qui fournissent un support direct pour des structures plus abstraites. Les relations sont une structure assez abstraite, donc je dirais que tout ce qui soutient les relations est de haut niveau par définition.

Le SQL pur est généralement décrit comme étant un langage déclaratif, avec quelques bits de procédure cloués par les différents fournisseurs. Le fait que SQL ne supporte pas les fonctions en tant que variables me semble le disqualifier immédiatement en tant que langage fonctionnel.

SQL est un langage relationnel basé sur un ensemble auquel ont été ajoutées des fonctionnalités procédurales.

Je ne sais pas si je considérerais SQL fonctionnel, mais il a certains aspects des langages fonctionnels. Les variantes modernes de SQL (avec les bits procéduraux) ne sont certainement pas fonctionnelles.

Je pense que SQL est un sucre syntaxique autour de l'algèbre relationnelle + quelque chose de plus. L'algèbre relationnelle a beaucoup de pouvoir sur les langages fonctionnels, elle exploite en effet des fonctions de très haut pouvoir d'expression (sélection, projection, renommage, jointure, union, intersection ...). Mais pour autant que je sache, le traitement de base de l'algèbre relationnelle n'a généralement pas d'équivalent d'opérateur lambda, bien qu'il puisse être étendu avec un opérateur de récursivité de manière transparente.

Je pense que l'algèbre relationnelle est plutôt un langage algébrique. SQL, avec ses sous-requêtes, est passé de l'algèbre relationnelle pure à un style plus fonctionnel, mais sans opérateur lambda, je pense que ce n'est pas un langage entièrement fonctionnel. Je ne sais pas s'il pourrait être étendu à un langage fonctionnel complet de manière transparente, je ne suis pas expert dans ce domaine. Haskell possède quelques bibliothèques dans le but de créer des langages de base de données de très haut niveau.

Je ne connais pas toutes les subtilités de ce dont il a besoin pour qu'un langage soit qualifié de fonctionnel, mais Sql Server a introduit une manière très intéressante de travailler avec les fonctions. Une clause spéciale permet aux fonctions d'interagir ensemble dans une requête. Cela s'appelle Appliquer. Lorsque j'ai expliqué cela à un ancien programmeur APL, il m'a dit qu'une clause similaire existait dans APL pour un objectif similaire. La clause Apply permet de passer un ensemble d'attributs de la ligne d'une table ou de la ligne d'une fonction de table en entrée à une autre fonction. Cela étant dit, j'ai imposé une restriction sur le type de fonction de table à écrire pour être considérée comme fonctionnelle. Le doit être déclaré en ligne, ce qui signifie qu'il est exprimé comme une seule instruction select. Cela impose de n'avoir aucune variable. De telles requêtes avec beaucoup de logique peuvent être écrites à condition d'utiliser des expressions de table communes qui permettent ensuite de transformer les expressions en colonne, une sorte de variable immuable qui peut être réutilisée dans d'autres CTE. En fin de compte, la fonction devient une très grande macro qui rend l'optimiseur libre d'optimiser la façon dont il a besoin.La seule chose qui manque aux gens est quelques astuces simples pour écrire une logique conditionnelle et déclaré des données prenant en charge la logique dans la requête. Enfin, certaines fonctions utilisant la clause over sont nécessaires pour que les résultats continuent d'être une valeur utilisable dans une ligne à partir d'autres lignes, mais il serait un peu long de travailler ici. La seule chose qui manque aux gens est quelques astuces simples pour écrire une logique conditionnelle et déclarer des données supportant la logique dans la requête. Enfin, certaines fonctions utilisant la clause over sont nécessaires pour que les résultats continuent d'être une valeur utilisable dans une ligne à partir d'autres lignes, mais il serait un peu long de travailler ici. La seule chose qui manque aux gens est quelques astuces simples pour écrire une logique conditionnelle et déclarer des données supportant la logique dans la requête. Enfin, certaines fonctions utilisant la clause over sont nécessaires pour que les résultats continuent d'être une valeur utilisable dans une ligne à partir d'autres lignes, mais il serait un peu long de travailler ici.