SQL est-il fondamentalement une instance spécifique au domaine de map + fold + filter?
Il me semble que le SQL suivant:
SELECT name
FROM fruits
WHERE calories < 100 est juste du sucre syntaxique pour l'opération map + filtre + fold suivante:
var fruits = [{id : 1, name: 'orange', calories : 100},
{id : 2, name : 'banana', calories : 150},
{id : 3, name: 'apple', calories : '50'}];
fruits.map(function(fruit) { return { name : fruit.name, calories : fruit.calories })
.filter(function(obj) { return obj.calories < 100 })
.reduce(function (accumulator, obj) { accumulator + "\n" + val.name; });Est-ce une coïncidence ou existe-t-il une équivalence sémantique solide qui peut être prouvée? Comment, en gros?
Je sais que dans la pratique, SQL a beaucoup de cloches et de sifflets, mais au fond, est-ce simplement une opération de filtrage de carte?
L'article suivant est pertinent: http://blogs.msdn.com/b/doriancorompt/archive/2013/01/21/bringing-the-querying-power-of-sql-to-javascript.aspx
functional-programming
sql
dsl
Sridhar Sarnobat
la source
la source
Réponses:
Jetez un oeil à LINQ , qui prend les concepts de base derrière SQL et le généralise à la programmation orientée objet. L'
Whereopérateur est un filtre standard, l'Selectopérateur est une projection / carte, etc. Toutes les opérations de requête SQL de base sont représentées dans LINQ, implémentées à l'aide de fonctions d'ordre supérieur, donc oui, vous avez raison dans votre compréhension intuitive de SQL.La grande différence entre l'exemple que vous avez et le fonctionnement d'une base de données relationnelle est que SQL est conçu avec un ensemble très limité de commandes à l'esprit. Ce n'est pas Turing-complete et les concepteurs de bases de données savent ce qu'il peut et ne peut pas faire, ce qui leur permet de concevoir le système beaucoup plus facilement pour optimiser les requêtes beaucoup plus que ce qui serait possible avec une simple
Mapénumération d'un ensemble de données élément par élément.la source
SQL est basé sur l'algèbre relationnelle et le calcul relationnel tuple, et non sur des fonctions d'ordre supérieur ou une programmation fonctionnelle. Alors que SELECT, FROM et WHERE ont des fonctions analogues dans d'autres langages, SQL lui-même ne prend pas en charge les fonctions d'ordre supérieur généralisées, mais uniquement les fonctions "d'ordre supérieur" que le langage lui-même définit.
Étant donné que SQL ne vous permet pas d'écrire vos propres fonctions personnalisées d'ordre supérieur, il ne peut être dit avec aucune autorité que le langage prend en charge les fonctions d'ordre supérieur.
la source