Faut-il standardiser le NoSQL avec un langage de requêtes unique ?

[Katleen Erna]

Faut-il standardiser le NoSQL avec un langage de requêtes unique ? Deux chercheurs de Microsoft proposent le "coSQL"

Erik Meijer et Gavin Bierman sont chercheurs pour Microsoft. En étudiant les bases de données, ils en sont arrivés à la conclusion que les BDD NoSQL avaient besoin d'être standardisées.

Car ce marché, en pleine croissance, est en effet très fragmenté. "Programmer, déployer et administrer des solutions NoSQL demande des connaissances spécialisées qui ne sont pas forcement les mêmes pour les différents produits des différents vendeurs", notent les chercheurs.

Ils expliquent que ce type de base de donnée est de plus en plus répandu (un engouement qui ressemble au fleurissement des bases de données relationnelles au début des années 1970), et que cette extension ne peut se poursuivre ainsi.

Mais loin de se contenter de critiquer la situation actuelle, ils y apportent aussi une solution concoctée par leurs soins : un query langage standardisé et un modèle mathématique pour les données, afin d'unifier les modèles NoSQL et SQL. Ils appellent cela le "coSQL".

Selon eux, un langage de manipulation de données standardisé accélérerait l'adoption de masse des technologies NoSQL pour les bases de données, en réduisant la fragmentation du marché, et les impacts négatifs qu'elle peut avoir sur les développeurs. Un peu comme ce qui s'était passé dans les seventies, où les bases relationnelles avaient réellement pris leur envol avec l'arrivée du langage standardisé SQL (qui évitait aux développeurs d'apprendre tous les langages spécifiques à chaque base).

Et si cela a marché pour l'une, pourquoi cela ne marcherait pas pour l'autre ?

"Contrairement à ce que l'on pourrait croire, SQL et coSQL ne sont pas diamétralement opposés mais plutôt connectés par de belles théories mathématiques", concluent les deux chercheurs.

Mais, comme beaucoup avant elle, cette toute jeune théorie rencontre déjà ses détracteurs.

Source : Le magazine de l'Association for Computing Machinery

Et vous, qu'en pensez-vous ? Faut-il standardiser le NoSQL ?

[Wormus]

Si celà est possible, ça peut être intéressant mais j'attends de voir parce que ça me parait difficile.
Une base de données noSQL c'est plusieurs types de bases de données donc standardiser tout ça avec les SGBDR ... pas facile.
Et puis si ces bases de données ont vus le jour c'est surement pour de l'optimisation et donc est-ce que la standardisation ne risque pas de casser une partie du gain gagné ?
Wait and see ...

[Firwen]

Le NoSQL ne représente pas un type de base de données, mais un ensemble de types : orienté document, graph, HashTable distribuées...

Vouloir créer un langage commun entre des bases orientées graphes et des bases orientés documents, par exemple, qui n'ont rien en commun niveau structurel, n'est pas forcement une bonne idée....

[bugsan]

J'ai plutôt compris un langage par type de base.

[Julien Bodin]

Oui ce serait une excellente idée.

Mais du coup, inventer un genre de SQL pour des bases noSQL je trouve ça assez drôle

[marten.cylemb]

Si cela se réalisait, à quand le NoCoSQL ?

[kedare]

Contre, ca risquerait d'empêcher la bonne utilisation des fonctionnalités uniques de chaque systèmes (genre du versonning pour certains), on aurait encore des puristes qui viendrait se plaindre dés qu'un système modifierait légèrement le langage ou l'entendrait de façon non standard...

[unBonGars]

Je ne connais pas assez noSql mais on pourrait résumer cette news à une passerelle sql / noSql.
Si j'ai tout compris, noSQL optimise massivement le multi-user (dans le cas des sites web notamment).
En comparant sql avec le vieil xBase (dBase, clipper, Fox, ...), il est évident que sql fait gagner un temps fou lors du développement en offrant notamment des fonctions statistiques qui demanderaient une 30aine de lignes de code C# par exemple (group by... having...).
Mais cette façon toute particulière qu'Sql a de dire "le serveur s'occupe de tout" pose des problèmes d'optimisation. De même , SQL ne dit pas explicitement d'utiliser un index donné et n'accepte pas les indexes partiels. Certes Oracle ajoute au SQL des éléments de diagramme d’exécution mais différents des autres éditeurs, on en est donc au même point d'incompatibilités coté SQL et noSQL.

Comme SQL est déjà une implémentation de la théorie des ensembles (programme de 6eme en maths - rappelez vous les deux patates). On s'attend à ce que le nouveau standard formalise l'information sur une base différente.

A ce stade, il faudrait donner des exemples , dire simplement que noSql n'est pas standard est un peu court (c'est une partie de sa définition), il faudrait qu'un expert en noSql donne son avis et peut être quelques exemples pour qu'on se rende compte. Autre question : Qui en France utilise noSql ? je comprends que facebook ou Google soient interressés vu leur volume mais dans l'exagone, à part l'administration des impôts les jours de dépôt , qui traite assez de volume pour avoir intéret à sortir de sql ?
Quelqu'un a une idée ?

[EDIT] : Référence nécessaire : http://fr.wikipedia.org/wiki/NoSQL

[psykokarl]

C'est une évolution qui me parait naturelle.

Je me suis demandé à plusieurs reprise si l’engouement pour les technologies noSQL n'était pas révélateur d'un manque de compétence en SQL de certains développeurs.

Le SQL est un langage de requête complet. Il permet de récupérer n'importe quel jeux de donnée à partir d'une description basée sur des opérations sur des ensembles.
Il faut faire la distinction entre le SQL en tant que langage de requête et le moteur qui retrouve/modifie un jeux. Rien n’empêche en théorie d'utiliser du SQL pour retrouver un jeux de données dans un SGBD "noSQL". Reste à implémenter un moteur viable et assez performant pour ne pas trop plomber les perfs.
Il pourrait être intéressant de créer des standards qui représenteraient d'autres paradigmes que le celui du SQL, mais c'est plus un sujet de recherche.
Je vois difficilement une industrie créer quelque chose de propre et de complet.

On pourrait faire une analogie entre le SQL+SGBDR cache au développeur toute la partie de recherche et indexation de données le la POO+garbage collector qui cache au développeur l'allocation et la desallocation de mémoire.
Il y aura des pros et des antis. Les deux systèmes ayant leurs avantages et leurs inconvénients.

[iznogoudmc]

Beau discours, mais avant tout de quelle branche de NoSQL parlent-ils ? Des bases clef/valeur ? Orientées colonnes (d'ailleurs, à ma connaissance il en existe déjà une qui permet d'utiliser SQL : Sybase IQ) ? Objets ? Orientées documents ? Orientées graphes ? Multivaluées ? autre ?

[marten.cylemb]

Envoyé par iznogoudmc

Beau discours, mais avant tout de quelle branche de NoSQL parlent-ils ? Des bases clef/valeur ? Orientées colonnes (d'ailleurs, à ma connaissance il en existe déjà une qui permet d'utiliser SQL : Sybase IQ) ? Objets ? Orientées documents ? Orientées graphes ? Multivaluées ? autre ?

Je ne suis pas du tout expert en matière de NoSQL, d'ailleurs je n'ai fait qu'essayer mongodb (une base en mode document), mais d'après ce que tu dis, les différences structurelles me semble sacrément hétérogènes..

Certains questions se posent donc de manière très légitime:

• Est-ce que cette standardisation apporterait une réelle valeur ajoutée ?
• Est-ce que cela ne détruirait pas de facto l'intérêt porté par ces bases de données (dont le principal objet est leur spécificité si j'ai bien compris) ?
• Est-ce que cela est tout bonnement réalisable ?

[iznogoudmc]

Envoyé par marten.cylemb

d'après ce que tu dis, les différences structurelles me semble sacrément hétérogènes..

En effet, il n'y a pas un NoSQL, mais des NoSQL : c'est actuellement en pleine effervescence (même sans parler du phénomène de mode)

Envoyé par marten.cylemb

Est-ce que cette standardisation apporterait une réelle valeur ajoutée ?

A mon avis : OUI... mais modèle par modèle. Par exemple pouvoir faire ses PUT et GET toujours de la même façon serait un plus dans l'utilisation des bases clef/valeur. Idem pour les bases orientées graphe, colonnes, documents, etc. MAIS.... en tenant compte des spécificités de chaque modèle.

Envoyé par marten.cylemb

Est-ce que cela est tout bonnement réalisable ?

Aujourd'hui je ne pense pas, chacun ayant intérêt à mettre en avant ce que sa base a de plus.... Ou alors un socle commun (modèle par modèle). Mais dans l'avenir (et pas forcément lointain) je pense qu'on y viendra naturellement.

[marten.cylemb]

Envoyé par iznogoudmc

Aujourd'hui je ne pense pas, chacun ayant intérêt à mettre en avant ce que sa base a de plus.... Ou alors un socle commun (modèle par modèle). Mais dans l'avenir (et pas forcément lointain) je pense qu'on y viendra naturellement.

En fait, j'ai aussi peur qu'une standardisation prématurée annihile le foisonnement d'idées qui fait la diversité actuelle des bases NoSQL aujourd'hui, parce que demain il faudra coller au standard et qu'on ne pourra plus "tout se permettre" pour améliorer les bases NoSQL..

[SQLpro]

Moi je suis totalement contre le fait de normaliser NoSQL... ;-)
La normalisation, c'est pour les has been !

Avant la révolution industrielle au 18e siècle, chaque seigneur imposait sur son territoire ses propres mesures de poids de volume que le commerçant devait acheter fort cher auprès du seigneur. C'était une forme d'impôt.
Les entreprises ont été obligée de se conformer à des standards et des normes, car cette situation à conduit à de nombreux accident mortels lors de l'avènement du chemin de fer :
- chaque région ayant ses pas de filetages, ses écrous et ses boulons, il a fallut dépenser trois fois plus pour adapter les éléments de structure au fur et à mesure de l'avancé des rails, ceci était contre productif....
- chaque village ayant son heure propre, les premiers trains se télescopaient et il en résultait des accidents mortels.

Bref je suis toujours sidéré de voir des gens comme firwen ou kedare s'opposer à une normalisation... Je ne peut pas m'empêcher de penser que ces gens là auraient fait d'excellent tyrans !

A +

[Oishiiii]

Il ne faut pas prendre cet article au sérieux, il est bourré d'approximations et laisse à penser que les auteurs n'ont qu'une connaissance superficielle de la théorie relationnelle.

The closed-world assumption, however, is in direct contradiction with distribution and scale-out

Ted Codd doit se retourner dans sa tombe. Ou comment des aspects matériels, physiques, influencent un système logique.

In this article we present a mathematical data model for the most common noSQL databases—namely, key/value relationships—and demonstrate that this data model is the mathematical dual of SQL's relational data model of foreign-/primary-key relationships.

Avant de démontrer il faudrait commencer par présenter et définir..

J'aimerai que les auteurs définissent ce qu'ils entendent par : "relational model", "normalized", "foreign-/primary-key data model", ou ne serait-ce que la notion de modèle..

Ils confondent comme souvent dans le monde NoSQL, le modèle relationnel et le SQL...