Publicité
+ Répondre à la discussion Actualité déjà publiée
Affichage des résultats 1 à 11 sur 11
  1. #1
    Responsable Actualités

    Avatar de Hinault Romaric
    Homme Profil pro Hinault Romaric
    Consultant
    Inscrit en
    janvier 2007
    Messages
    3 511
    Détails du profil
    Informations personnelles :
    Nom : Homme Hinault Romaric
    Localisation : Cameroun

    Informations professionnelles :
    Activité : Consultant
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : janvier 2007
    Messages : 3 511
    Points : 51 002
    Points
    51 002

    Par défaut 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

  2. #2
    Membre chevronné Avatar de Julien Bodin
    Homme Profil pro Julien Bodin
    Ingénieur développement logiciels
    Inscrit en
    février 2009
    Messages
    462
    Détails du profil
    Informations personnelles :
    Nom : Homme Julien Bodin
    Âge : 27
    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 : 462
    Points : 791
    Points
    791

    Par défaut

    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.

  3. #3
    Membre Expert
    Homme Profil pro
    Développeur informatique
    Inscrit en
    avril 2010
    Messages
    394
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations professionnelles :
    Activité : Développeur informatique
    Secteur : Distribution

    Informations forums :
    Inscription : avril 2010
    Messages : 394
    Points : 1 642
    Points
    1 642

    Par défaut

    Citation Envoyé par Hinault Romaric Voir le message
    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

  4. #4
    Expert Confirmé Sénior

    Inscrit en
    décembre 2003
    Messages
    2 460
    Détails du profil
    Informations forums :
    Inscription : décembre 2003
    Messages : 2 460
    Points : 5 110
    Points
    5 110

    Par défaut

    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...
    Les brevets ? Le type qui a inventé l'eau chaude doit être grave blindé de thunes !

  5. #5
    Expert Confirmé Sénior

    Inscrit en
    décembre 2003
    Messages
    2 460
    Détails du profil
    Informations forums :
    Inscription : décembre 2003
    Messages : 2 460
    Points : 5 110
    Points
    5 110

    Par défaut

    Citation Envoyé par Mako 5013 Voir le message
    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
    Les brevets ? Le type qui a inventé l'eau chaude doit être grave blindé de thunes !

  6. #6
    Membre expérimenté
    Inscrit en
    décembre 2004
    Messages
    420
    Détails du profil
    Informations forums :
    Inscription : décembre 2004
    Messages : 420
    Points : 508
    Points
    508

    Par défaut

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

  7. #7
    Membre Expert Avatar de Firwen
    Inscrit en
    juin 2009
    Messages
    434
    Détails du profil
    Informations forums :
    Inscription : juin 2009
    Messages : 434
    Points : 1 023
    Points
    1 023

    Par défaut

    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.
    It's not a bug, it's a feature
    Site web : www.firwen.org
    GPG id : 0x8C717673

  8. #8
    Membre Expert
    Profil pro
    Inscrit en
    janvier 2007
    Messages
    1 452
    Détails du profil
    Informations personnelles :
    Âge : 29
    Localisation : France, Paris (Île de France)

    Informations forums :
    Inscription : janvier 2007
    Messages : 1 452
    Points : 1 914
    Points
    1 914

    Par défaut

    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+

  9. #9
    Membre confirmé
    Inscrit en
    mars 2011
    Messages
    114
    Détails du profil
    Informations forums :
    Inscription : mars 2011
    Messages : 114
    Points : 249
    Points
    249

    Par défaut

    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 .

  10. #10
    Membre habitué
    Homme Profil pro Georges DICK
    Architecte de système d'information
    Inscrit en
    juin 2006
    Messages
    87
    Détails du profil
    Informations personnelles :
    Nom : Homme Georges DICK
    Âge : 49
    Localisation : Monaco

    Informations professionnelles :
    Activité : Architecte de système d'information
    Secteur : Conseil

    Informations forums :
    Inscription : juin 2006
    Messages : 87
    Points : 140
    Points
    140

    Par défaut 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 ?

  11. #11
    Membre confirmé
    Inscrit en
    mars 2011
    Messages
    114
    Détails du profil
    Informations forums :
    Inscription : mars 2011
    Messages : 114
    Points : 249
    Points
    249

    Par défaut

    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 !

Liens sociaux

Règles de messages

  • Vous ne pouvez pas créer de nouvelles discussions
  • Vous ne pouvez pas envoyer des réponses
  • Vous ne pouvez pas envoyer des pièces jointes
  • Vous ne pouvez pas modifier vos messages
  •