Les développeurs de CouchDB et SQLite créent UnQL

Hinault Romaric · 01/08/2011, 13h04

Les développeurs de CouchDB et SQLite créent UnQL
Le nouveau langage de requêtes unifié NoSQL

Le mouvement NoSQL a vu la naissance de plusieurs systèmes de gestion de bases de données non relationnels comme CouchDB ou encore Apache Cassandra.

Cependant, chaque SGBD offre sa propre interface d’accès et de manipulation de données, limitant ainsi la capacité des entreprises à utiliser plusieurs SGBD NoSQL ou encore obligeant les développeurs à avoir des connaissances spécialisées sur chaque outil.

Les développeurs des SGBD open source NoSQL CouchDB et SQLite ont soumis conjointement la spécification d’un nouveau langage de requêtes baptisé UnQL (prononcé "Uncle") pour standardiser le NoSQL.

UnQL est un langage de haut niveau, qui permettra d’effectuer des requêtes sur les documents des bases de données NoSQL. L’objectif de NoSQL selon James Phillips co-fondateur de Couchbase est de créer un point commun entre les bases de données NoSQL.

Si le langage est adopté par d’autres fournisseurs de bases de données NoSQL, UnQL sera pour ces SGBD ce que SQL est pour les SGBD relationnels.

La syntaxe de UnQL est très similaire à celle de SQL, et comprend les instructions select, insert, update et delete, mais contrairement au SQL, UnQL ne requête pas sur les tables, mais sur des collections d’ensembles non ordonnés de documents.

Le langage comprend également en plus des concepts appropriés pour les données non-structurées et les formats de données auto-descriptifs des applications NoSQL.

En langage UnQL, un document sera un objet qui peut-être écrit en JSON (JavaScript Object Notation). Des nombres entiers simples, des nombres à virgule flottante et les chaines peuvent également être des documents.

Pour mémoire, des chercheurs de Microsoft avaient également mis au point un langage de requêtes baptisé coSQL pour standardiser le NoSQL.

Source : Le site UnQL

Et vous ?

Que-en pensez-vous?

Julien Bodin · 01/08/2011, 13h35

J'aime l'initiative, mais est-ce que cela valable pour tous les types de base de données NoSQL ou simplement celles "orientées documents" telles que CouchDB ou MongoDB ?

La news en elle-même parle de documents, ce qui du coup réduirait l'iniative à une sous-partie du NoSQL.

Mako 5013 · 01/08/2011, 14h24

Citation:

Envoyé par Hinault Romaric

Pour mémoire, des chercheurs de Microsoft avaient également mis au point un langage de requêtes baptisé coSQL pour standardiser le NoSQL.

Et quelqu'un sait ce qu'il est advenu de coSQL ?

Parce que vouloir faire des standards, c'est bien, encore faut-il qu'ils soient utilisés par tout le monde... Si chacun implémente son propre standard... ben ce n'est plus un standard du tout !

Mako

Traroth2 · 01/08/2011, 14h35

Bonne initiative, mais qui soulève une foule de questions :

Quelle est la licence de cette spécification ? Je ne l'ai trouvé nulle part sur le site.
Quelles bases NoSQL sont actuellement compatibles avec cette spec ? On pourrait imaginer que CouchDB doit l'être, mais ce n'est pas vraiment dit.
Que vient faire SQLite là-dedans ? C'est une base de données relationnelle...

Une remarque en plus : pour l'instant, c'est un peu léger. Le site ne montre pratiquement que la grammaire d'une requête UnQL, quelques explications sommaires et la liste des participants (2). Pas vraiment à la hauteur des enjeux...

Traroth2 · 01/08/2011, 14h42

Citation:

Envoyé par Mako 5013

Et quelqu'un sait ce qu'il est advenu de coSQL ?

Parce que vouloir faire des standards, c'est bien, encore faut-il qu'ils soient utilisés par tout le monde... Si chacun implémente son propre standard... ben ce n'est plus un standard du tout !

Mako

Pour l'instant, le coSQL, c'est juste un article sur le site de l'ACM par deux chercheurs de Microsoft et une présentation sur MSDN. Il serait intéressant de savoir dans quelle mesure les deux créateurs de UnSQL se sont inspirés de ces travaux, d'ailleurs.

http://channel9.msdn.com/Forums/Coff...-is-CoSQL-talk

Thorna · 01/08/2011, 16h20

C'est moi qui dort encore, ou c'est exactement du SQL ?

Firwen · 01/08/2011, 16h51

Citation:

J'aime l'initiative, mais est-ce que cela valable pour tous les types de base de données NoSQL ou simplement celles "orientées documents" telles que CouchDB ou MongoDB ?

J'ai de gros doutes, je vois pas trop comment modeliser une NoSQL orienté graph avec ça.

kaymak · 02/08/2011, 10h12

Je n'ai pas toute vos connaissances dans le domaine nosql, mais justement pour un non averti tel que moi, ce genre d'outil sera grandement apprécié.

J'espère qu'ils en feront un standard et que cela réponde à toutes vos demandes !
Et tant qu'à faire, si il pouvait éviter l'écueil du SQL et ses mots clé spécifiques à chaque moteur cela montrerait la maturité de ces nouveaux outils malgré leur jeune âge.

a+

psykokarl · 02/08/2011, 10h23

Il y a déjà eu un sujet similaire il y a quelques temps, à savoir : "Faut-il standardiser le NoSQL avec un langage de requêtes unique ?".
Je répondrais grosso modo la même chose.

Il existe un langage de requête standard: Le SQL. C'est un langage complet qui permet de récupérer n'importe quel jeux de données à partir d'une simple requête.
A coté de cela il y a le moteur qui va interpréter la requête pour rechercher ou modifier les données. Ce moteur peut être conçu de manière à privilégié la vitesse, la fiabilité, ou n'importe quel autre critère qui paraitra important à son concepteur. Dans ce cas pourquoi pas utiliser des technologies NoSQL ?

J'ai toujours autant de mal le terme NoSQL qui est au final rien de plus qu'une provocation.
Que des dev aient du mal avec le SQL et préfèrent un langage d'avantage en accord avec leur paradigme de prédilection... soit ! Les langages sont fait pour ça !
Que des dev préfèrent pour des raisons de performances utiliser un autre moteur ou qu'il essaient de gagner des perfs en enlevant la partie interpréteur de code... soit ! Le boulot de dev c'est aussi ça !

Seulement évitons de voir des révolutions partout et ne mélangeons pas ces deux concepts. Il se trouve que le SQL rends mieux compte des relations entre les données que la POO qui met d'avantage l'accent sur les propriétés de chaque donnée.
On en revient donc sur le débat à propos des différents types de langage de programmation.

J'éviterai de parler des avantages de l'objet, du fonctionnel, de l’impératif, ou du relationnel ici. Ce n'est pas vraiment le sujet et le risque d'être "sanctionné" par ceux qui ne sont pas d'accord est trop grand

.

iznogoudmc · 03/08/2011, 09h21

Le monde du NoSQL est très loin d'être stabilisé, les bases NoSQL sont pléthore, leurs modes de fonctionnement sont très nombreux et différents (quel point commun entre une base clef/valeur et une orientée graphe ???).

Dans de telles conditions, à quoi bon rechercher un langage de requêtes commun à toutes ces bases ?

D'un autre côté, faire un langage commun par type de base, pourquoi pas ?

psykokarl · 03/08/2011, 15h15

Le monde du NoSQL est encore jeune et les technologies y sont en phase de maturation. Les SGBD dites relationnelles sont vraisemblablement passé par la avant de devenir ce qu'elles sont. D'ailleurs, peut on réellement dire qu'elles ont quitté cette phase ?
La chasse au bugs et autres failles me parait sans fin...

L'utilité d'un langage requête commun c'est de pouvoir demander ce que l'on veut à la machine la façon la plus claire, la plus simple et la plus concise possible. Cela sans se préoccuper du fonctionnement du système qui exécute la requête.
A terme on pourra garder la même requête car on veut au la même chose au final et choisir le système ou l'archi le plus performant pour résoudre notre problème en fonction des contraintes qui nous sont imposées.

Très schématiquement avec la requête:

Select clef from une_source where valeur='toto'

La valeur "une_source" sera interprétée comme une table dans un SGBDR ou comme un fichier contenant des paires clef/valeur dans un SGBD basé clef/valeur.

Pour ce qui est des bases orientées graphes le même type d'équivalence est possible. Il suffit d'une requête récursive, avec de bon where et de bonnes jointures. Je donne pas d'exemple car j'ai la flemme mais je suis sur que vous me suivez

.

L'important est de dissocier le langage et le système. Tout ce qui peut être fait avec un langage Turing-complet peut être fait avec un autre langage Turing-complet.
- La demande "Donnes moi les pommes que vendent les boutiques qui vendent ces poires" fait appel au concept de liens entre les pommes, les poires et les boutiques. Un langage de type SQL est un choix judicieux pour retranscrire cette demande.
- La demande "Donnes moi le chemin le plus court entre Chez moi et Justine qui passe devant chez le fleuriste et qui évite la rue de chez Robert et la rue du commissariat" peut également être retranscrite en SQL mais plus c'est beaucoup compliqué. Un langage orienté graphe serait alors le bienvenu...

Même avec une appli qui fait 99,99% de calcul d'itinéraire et qui justifierai le choix d'un SGBD orienté graphe, il sera toujours intéressant de demander la liste des fleuristes ouvert au moment ou je pars.
Pour 0.01% des demandes je crois qu'il ne vaut pas le coups d'installer deux SGBD de type différents et de les faire communiqués entre eux.
D’où l’intérêt du langage de requête commun, d’où la pertinence de la séparation langage/système de base de données, d’où le fait que NoSQL n'a que peu d’intérêt pour moi tant que le découplage langage/système n'est pas mis en avant.
Cela dit avec la volonté de faire un langage commun au technos NoSQL qui ironiquement se rapproche du SQL, on s'en rapproche lentement mais surement !

01/08/2011, 13h04	#1
Hinault Romaric Chroniqueur Actualités Hinault Romaric Consultant Inscription : janvier 2007 Messages : 2 119 Détails du profil Informations personnelles : Nom : Hinault Romaric Localisation : Cameroun Informations professionnelles : Activité : Consultant Secteur : High Tech - Éditeur de logiciels Informations forums : Inscription : janvier 2007 Messages : 2 119 Points : 31 186 Points : 31 186	Les développeurs de CouchDB et SQLite créent UnQL Les développeurs de CouchDB et SQLite créent UnQL Le nouveau langage de requêtes unifié NoSQL Le mouvement NoSQL a vu la naissance de plusieurs systèmes de gestion de bases de données non relationnels comme CouchDB ou encore Apache Cassandra. Cependant, chaque SGBD offre sa propre interface d’accès et de manipulation de données, limitant ainsi la capacité des entreprises à utiliser plusieurs SGBD NoSQL ou encore obligeant les développeurs à avoir des connaissances spécialisées sur chaque outil. Les développeurs des SGBD open source NoSQL CouchDB et SQLite ont soumis conjointement la spécification d’un nouveau langage de requêtes baptisé UnQL (prononcé "Uncle") pour standardiser le NoSQL. UnQL est un langage de haut niveau, qui permettra d’effectuer des requêtes sur les documents des bases de données NoSQL. L’objectif de NoSQL selon James Phillips co-fondateur de Couchbase est de créer un point commun entre les bases de données NoSQL. Si le langage est adopté par d’autres fournisseurs de bases de données NoSQL, UnQL sera pour ces SGBD ce que SQL est pour les SGBD relationnels. La syntaxe de UnQL est très similaire à celle de SQL, et comprend les instructions select, insert, update et delete, mais contrairement au SQL, UnQL ne requête pas sur les tables, mais sur des collections d’ensembles non ordonnés de documents. Le langage comprend également en plus des concepts appropriés pour les données non-structurées et les formats de données auto-descriptifs des applications NoSQL. En langage UnQL, un document sera un objet qui peut-être écrit en JSON (JavaScript Object Notation). Des nombres entiers simples, des nombres à virgule flottante et les chaines peuvent également être des documents. Pour mémoire, des chercheurs de Microsoft avaient également mis au point un langage de requêtes baptisé coSQL pour standardiser le NoSQL. Source : Le site UnQL Et vous ? Que-en pensez-vous? __________________ Si déboguer est l’art de corriger les bugs, alors programmer est l’art d’en faire Mon blog Mes articles En posant correctement votre problème, on trouve la moitié de la solution
	30

01/08/2011, 14h35	#4
Traroth2 Membre Expert Inscription : décembre 2003 Messages : 1 336 Détails du profil Informations forums : Inscription : décembre 2003 Messages : 1 336 Points : 2 382 Points : 2 382	Bonne initiative, mais qui soulève une foule de questions : Quelle est la licence de cette spécification ? Je ne l'ai trouvé nulle part sur le site. Quelles bases NoSQL sont actuellement compatibles avec cette spec ? On pourrait imaginer que CouchDB doit l'être, mais ce n'est pas vraiment dit. Que vient faire SQLite là-dedans ? C'est une base de données relationnelle... Une remarque en plus : pour l'instant, c'est un peu léger. Le site ne montre pratiquement que la grammaire d'une requête UnQL, quelques explications sommaires et la liste des participants (2). Pas vraiment à la hauteur des enjeux... __________________ Traroth
	20

01/08/2011, 16h20	#6
Thorna Membre éclairé Inscription : décembre 2004 Messages : 304 Détails du profil Informations forums : Inscription : décembre 2004 Messages : 304 Points : 369 Points : 369	C'est moi qui dort encore, ou c'est exactement du SQL ?
	00

03/08/2011, 09h21	#10
iznogoudmc Membre habitué Georges DICK Architecte de système d'information Inscription : juin 2006 Messages : 78 Détails du profil Informations personnelles : Nom : Georges DICK Âge : 48 Localisation : Monaco Informations professionnelles : Activité : Architecte de système d'information Secteur : Conseil Informations forums : Inscription : juin 2006 Messages : 78 Points : 135 Points : 135	Mais pourquoi faire ??? Le monde du NoSQL est très loin d'être stabilisé, les bases NoSQL sont pléthore, leurs modes de fonctionnement sont très nombreux et différents (quel point commun entre une base clef/valeur et une orientée graphe ???). Dans de telles conditions, à quoi bon rechercher un langage de requêtes commun à toutes ces bases ? D'un autre côté, faire un langage commun par type de base, pourquoi pas ?
	10

03/08/2011, 15h15	#11
psykokarl Membre habitué Inscription : mars 2011 Messages : 54 Détails du profil Informations forums : Inscription : mars 2011 Messages : 54 Points : 111 Points : 111	Le monde du NoSQL est encore jeune et les technologies y sont en phase de maturation. Les SGBD dites relationnelles sont vraisemblablement passé par la avant de devenir ce qu'elles sont. D'ailleurs, peut on réellement dire qu'elles ont quitté cette phase ? La chasse au bugs et autres failles me parait sans fin... L'utilité d'un langage requête commun c'est de pouvoir demander ce que l'on veut à la machine la façon la plus claire, la plus simple et la plus concise possible. Cela sans se préoccuper du fonctionnement du système qui exécute la requête. A terme on pourra garder la même requête car on veut au la même chose au final et choisir le système ou l'archi le plus performant pour résoudre notre problème en fonction des contraintes qui nous sont imposées. Très schématiquement avec la requête: Select clef from une_source where valeur='toto' La valeur "une_source" sera interprétée comme une table dans un SGBDR ou comme un fichier contenant des paires clef/valeur dans un SGBD basé clef/valeur. Pour ce qui est des bases orientées graphes le même type d'équivalence est possible. Il suffit d'une requête récursive, avec de bon where et de bonnes jointures. Je donne pas d'exemple car j'ai la flemme mais je suis sur que vous me suivez . L'important est de dissocier le langage et le système. Tout ce qui peut être fait avec un langage Turing-complet peut être fait avec un autre langage Turing-complet. - La demande "Donnes moi les pommes que vendent les boutiques qui vendent ces poires" fait appel au concept de liens entre les pommes, les poires et les boutiques. Un langage de type SQL est un choix judicieux pour retranscrire cette demande. - La demande "Donnes moi le chemin le plus court entre Chez moi et Justine qui passe devant chez le fleuriste et qui évite la rue de chez Robert et la rue du commissariat" peut également être retranscrite en SQL mais plus c'est beaucoup compliqué. Un langage orienté graphe serait alors le bienvenu... Même avec une appli qui fait 99,99% de calcul d'itinéraire et qui justifierai le choix d'un SGBD orienté graphe, il sera toujours intéressant de demander la liste des fleuristes ouvert au moment ou je pars. Pour 0.01% des demandes je crois qu'il ne vaut pas le coups d'installer deux SGBD de type différents et de les faire communiqués entre eux. D’où l’intérêt du langage de requête commun, d’où la pertinence de la séparation langage/système de base de données, d’où le fait que NoSQL n'a que peu d’intérêt pour moi tant que le découplage langage/système n'est pas mis en avant. Cela dit avec la volonté de faire un langage commun au technos NoSQL qui ironiquement se rapproche du SQL, on s'en rapproche lentement mais surement !
	30

01/08/2011, 13h35	#2
Julien Bodin Membre chevronné Julien Bodin Ingénieur développement logiciels Inscription : février 2009 Messages : 442 Détails du profil Informations personnelles : Nom : Julien Bodin Âge : 25 Localisation : France, Calvados (Basse Normandie) Informations professionnelles : Activité : Ingénieur développement logiciels Secteur : High Tech - Éditeur de logiciels Informations forums : Inscription : février 2009 Messages : 442 Points : 663 Points : 663	J'aime l'initiative, mais est-ce que cela valable pour tous les types de base de données NoSQL ou simplement celles "orientées documents" telles que CouchDB ou MongoDB ? La news en elle-même parle de documents, ce qui du coup réduirait l'iniative à une sous-partie du NoSQL.
	01

02/08/2011, 10h12	#8
kaymak Membre Expert Inscription : janvier 2007 Messages : 1 452 Détails du profil Informations personnelles : Âge : 27 Localisation : France, Paris (Île de France) Informations forums : Inscription : janvier 2007 Messages : 1 452 Points : 1 914 Points : 1 914	Je n'ai pas toute vos connaissances dans le domaine nosql, mais justement pour un non averti tel que moi, ce genre d'outil sera grandement apprécié. J'espère qu'ils en feront un standard et que cela réponde à toutes vos demandes ! Et tant qu'à faire, si il pouvait éviter l'écueil du SQL et ses mots clé spécifiques à chaque moteur cela montrerait la maturité de ces nouveaux outils malgré leur jeune âge. a+
	01

02/08/2011, 10h23	#9
psykokarl Membre habitué Inscription : mars 2011 Messages : 54 Détails du profil Informations forums : Inscription : mars 2011 Messages : 54 Points : 111 Points : 111	Il y a déjà eu un sujet similaire il y a quelques temps, à savoir : "Faut-il standardiser le NoSQL avec un langage de requêtes unique ?". Je répondrais grosso modo la même chose. Il existe un langage de requête standard: Le SQL. C'est un langage complet qui permet de récupérer n'importe quel jeux de données à partir d'une simple requête. A coté de cela il y a le moteur qui va interpréter la requête pour rechercher ou modifier les données. Ce moteur peut être conçu de manière à privilégié la vitesse, la fiabilité, ou n'importe quel autre critère qui paraitra important à son concepteur. Dans ce cas pourquoi pas utiliser des technologies NoSQL ? J'ai toujours autant de mal le terme NoSQL qui est au final rien de plus qu'une provocation. Que des dev aient du mal avec le SQL et préfèrent un langage d'avantage en accord avec leur paradigme de prédilection... soit ! Les langages sont fait pour ça ! Que des dev préfèrent pour des raisons de performances utiliser un autre moteur ou qu'il essaient de gagner des perfs en enlevant la partie interpréteur de code... soit ! Le boulot de dev c'est aussi ça ! Seulement évitons de voir des révolutions partout et ne mélangeons pas ces deux concepts. Il se trouve que le SQL rends mieux compte des relations entre les données que la POO qui met d'avantage l'accent sur les propriétés de chaque donnée. On en revient donc sur le débat à propos des différents types de langage de programmation. J'éviterai de parler des avantages de l'objet, du fonctionnel, de l’impératif, ou du relationnel ici. Ce n'est pas vraiment le sujet et le risque d'être "sanctionné" par ceux qui ne sont pas d'accord est trop grand .
	20

Outils de la discussion
Afficher une version imprimable Envoyer un lien vers cette page par email