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 ?

:fleche: Que-en pensez-vous?

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.

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

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...

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

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

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.

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+

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 :mrgreen:.

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 ?

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 :mrgreen:.

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 !

Au fait c'en est où sur super langage qu'est UnQL censé remplacé voire absorber le SQL ?

A +