Discussion :

[SQLpro]

Ce mouvement est bien entendu la conséquence désastreuse de la perte de connaissance sur ce que sont les données et l'intérêt des SGBDR en général comme outil central de toute application gérant des données.

Relisez l'article que j'ai posté sur le développement en base de données épaisse... Bien sur je suis à contre courant. Mais à contre courant du marketing, pas de la technologie....

Posez vous la bonne question, à savoir d'où vient ce mouvement contestataire ?

Il est assez simple de constater qu'il vient de deux horizons bien identifiés : ceux qui prônent le tout objet via notamment Java (un langage en perte de vitesse et désormais "acquis" par Oracle à travers Sun) et quelques autres industriels qui préféreraient vous voir plonger dans leurs solutions captives comme Google !

Quand aux SGBDR "SGBD-attributs/valeurs" ils ont 20 ans de retard. C'est un modèle qui a eu son heure de gloire un peu avant les SGBD relationnels, notamment avec Pick...

Bref, ce débat c'est Darwwin contre le créationnisme. Un mouvement très en vogue aux US en ce moment !

A +

[ladeche]

N'est-on pas en train de vouloir faire faire au SGBD des choses qui ne sont pas de son ressort ?

En l'occurrence j'ai compris le contraire. On est en train de vouloir faire faire à d'autres systèmes des choses qui sont du ressort du SGBD.

[savageman86]

Moi, ce que j'aimerais bien voir, c'est un exemple. Une petite base de test ou de démonstration, comme pour les tutos SQL, et quelques interrogations/ajouts/suppressions/modifications, juste pour avoir une idée de ce à quoi ça peut bien ressembler!

+1

[eomer212]

ouais, finalement, plutot que de faire des plans sur la comete, j'ai été voir, et ca me fait peur .. j'explique..
il veulent finalement, avoir quelque chose qui gére des tables de stockage mais sans relations entre elles, donc, ces relations (si elles sont necessaires) devront être externalisées dans le programme appelant.
finalement, pour ce qui est de la rapidité d'execution de requetes simples visant à ajouter, modifier ou recuperer du contenu, pourquoi pas, l'equivalent d'un fichier mais accessible depuis javascript.. et oui, javascript, on retrouve les stockages json et compagnies derriére ce nosql.
donc finalement, ce pourrait être une bonne solution, mais dans le cadre d'une demande de stockage et d'accés à des données indexées et sans possibilités de relations..
rapidité, simplicité. et tout ca..
le pendant de la chose, c'est que le sql permet de faire des choses assez magiques dés lors que l'on a pris le soin de reflechir et d'organiser ses données..
ici, l'organisation, la hierarchisation ne sont plus de mises.
on stocke les données et on les lit. point. finalement, ils reinventent le fichier plat
mais accessible depuis un javascript avec les délais d'internet!!!
woawww!!
une autre explication de ce besoin, est la haine de ces gens qui ont appris le javascript et ne peuvent pas acceder à des bases de données depuis le navigateur...c'est un besoin qui pourrait se comprendre, ponctuellement, mais d'un autre coté, le javascript n'est pas fait pour charger le navigateur qui doit rester un afficheur de resultats..
donc, pour moi, c'est du n'importe nawak..

[Keihilin]

ouais, finalement, plutot que de faire des plans sur la comete, j'ai été voir, et ca me fait peur

A part le mal réveillé en première page qui a pris ça comme une attaque directe sur MS SQL Server, personne ne tire de plans sur la comète

il veulent finalement, avoir quelque chose qui gére des tables de stockage mais sans relations entre elles, donc, ces relations (si elles sont necessaires) devront être externalisées dans le programme appelant.

Oui oui, c'est pas pour rien que BigTable est plusieurs fois cité comme exemple.

ici, l'organisation, la hierarchisation ne sont plus de mises.
on stocke les données et on les lit. point. finalement, ils reinventent le fichier plat

pour moi, c'est du n'importe nawak..

Tu sais, je connais pas mal de cobolistes qui continuent à accéder à DB2 en mode natif et à traiter les tables comme des fichiers plutôt que d'utiliser SQL; ils t'expliqueront le plus sérieusement du monde que SQL c'est n'importe quoi et que l'accès natif est plus rapide (ce qui est vrai à l'échelle du pouième de seconde).

Tu parles justement d'organisations des données, et c'est là la clé du problème. L'organisation des données induite par les SGBDR n'est pas la panacée absolue !

Face à de nouvelles problématiques rencontrées par Google ou Facebook, on tombe clairement sur des "faiblesses" du relationnel et il faut envisager de nouvelles approches.

Le problème est clairement que ces nouvelles approches ne se justifient que dans certains cas mais que malgré cela, il y a un risque d'effet de mode dans lequel les incompétents du SQL vont s'engouffrer...

[el_slapper]

(.../...)
Tu sais, je connais pas mal de cobolistes qui continuent à accéder à DB2 en mode natif et à traiter les tables comme des fichiers plutôt que d'utiliser SQL; ils t'expliqueront le plus sérieusement du monde que SQL c'est n'importe quoi et que l'accès natif est plus rapide (ce qui est vrai à l'échelle du pouième de seconde).(.../...)

Ca, c'est pour ma gueule. Réponse d'ingénieur : ça dépend.

J'ai une base contrat et une base produit. Je dois faire une transaction de création/modification/suppression : évidemment, le SQL sera supérieur.

Maintenant, je dois faire un batch qui scanne TOUS les contrats pour des raisons X ou Y(genre une revalorisation annuelle). Je peut faire un ordre SQL (Fetch / for update), ou alors une descente/remontée de base. Les deux solutions ont leurs avantages et leurs inconvénients. Le SQL pur sera plus lent. Le traitement sur fichier sera plus bavard(et il faut de toutes façons garder SQL pour manipuler les produits associés au contrat).

Mais ma conclusion va répondre à ça :

Le problème est clairement que ces nouvelles approches ne se justifient que dans certains cas mais que malgré cela, il y a un risque d'effet de mode dans lequel les incompétents du SQL vont s'engouffrer...

On vit dans un monde ou il existe des incompétents. C'est exact. Pour autant, il faut quand même que ces gens-là puissent être productifs, non? Dans mon exemple ci-dessus, traiter un fichier plat est plus accessible à un incompétent que faire du SQL pur.

L'objectif, c'est quoi? Vivre dans un monde de bisounounours ou tout est parfait, mais personne n'y comprend rien? Ou bien adopter des solutions plus besogneuses, mais que le commun des mortels saura maintenir?

A mon sens, une solution élégante mais que personne ne sait maintenir est une mauvaise solution.

[Shirraz]

On vit dans un monde ou il existe des incompétents. C'est exact. Pour autant, il faut quand même que ces gens-là puissent être productifs, non? Dans mon exemple ci-dessus, traiter un fichier plat est plus accessible à un incompétent que faire du SQL pur.

L'objectif, c'est quoi? Vivre dans un monde de bisounounours ou tout est parfait, mais personne n'y comprend rien? Ou bien adopter des solutions plus besogneuses, mais que le commun des mortels saura maintenir?

A mon sens, une solution élégante mais que personne ne sait maintenir est une mauvaise solution.

Ou de faire ne sorte que les personnes soient justes... formés ? S'il y a des incompétents, au lieu de leur filer des boués de secours, ils seraient peut-être mieux de les mettre à la photocopieuse ou les former aux outils nécéssaires.



'fin, perso je suis a fond dans le XML qui correspond bien à mes petits besoins, donc j'ai rien à dire de plus, je réagissait plus à l'idée qu'à la technologie :p

[Keihilin]

On vit dans un monde ou il existe des incompétents. C'est exact. Pour autant, il faut quand même que ces gens-là puissent être productifs, non?

Il faut que les incompétent puissent être productifs ? J'ai une meilleure suggestion : et si ils se recyclaient ? ou se formaient ?

C'est vraiment quelque chose de formidable dans le monde du développement informatique : l'incompétence est parfaitement tolérée du moment que tu produis !

C'est un peu comme si pour obtenir un diplôme d'architecte (en bâtiment) il suffisait de savoir dessiner.

bref, on s'égare...

[viking1404]

Lors d'une discussion avec un "professionnelle" celui-ci m'a indiqué qu'il n'utilisait plus que JPA, car il en avait marre d'écrire des requêtes SQL.

Traduction : je suis trop mauvais pour écrire des requêtes SQL qui fonctionnent du premier coup alors je prends une alternative qui ne me prend pas la tête.

Je ne dis pas que tous les fans de "noSQL" ne comprennent rien à SQL.

Je ne dis pas non plus que le "noSQL" c'est le mal. Il y a sans doute des cas ou c'est très utile.

Je dis juste que j'en ai marre de voir de plus en plus de technologies émerger pour principalement remplacer les incompétences de certaines personnes.

[mon_nom_est_personne]

Je dis juste que j'en ai marre de voir de plus en plus de technologies émerger pour principalement remplacer les incompétences de certaines personnes.

+1

[pseudocode]

Je dis juste que j'en ai marre de voir de plus en plus de technologies émerger pour principalement remplacer les incompétences de certaines personnes.

C'est pas forcément de l'incompétence, mais la force de l'habitude. La solution traditionnelle pour faire de la "persistance objet" en Java c'est:
- Un modèle objet simple (POJO)
- une mappeur Objet/Relationnel (ORM)
- une base de données relationnelle

Cette solution, bien que totalement fonctionnelle est loin d''être idéale : conflit Objet/Relationnel (impedance mismatch), Schéma en double (dépendances vs relations), conversion de type Java/SQL, ...

Et généralement, on se retrouve a recréer un langage de requête "orienté objet" au dessus du SQL, voir a taper directement dans la Base pour remonter des infos (comptage, existence, ...). Bref, beaucoup de boulot pour passer outre les contraintes de la solution "pojo+orm+sgbdr". Parfois on se rend compte qu'il est plus facile de faire un stockage brut des valeurs de l'objet (nom d'attribut+valeur) et d'écrire son propre système CRUD.

Les NoSQListes (!) ne sont pas contre l'utilisation des SGBDR, mais ils sont contre son utilisation à tout prix comme si c'était la seule solution possible.

[mon_nom_est_personne]

Les NoSQListes (!) ne sont pas contre l'utilisation des SGBDR, mais ils sont contre son utilisation à tout prix comme si c'était la seule solution possible.

+1 comme voirs des tables de stockage d'objet serialise. Jamais compris pourquoi.

[scheu]

Je dis juste que j'en ai marre de voir de plus en plus de technologies émerger pour principalement remplacer les incompétences de certaines personnes.

Tu résumes parfaitement mon opinion également

Cette histoire de NoSQL, ça sent les gens qui n'ont jamais réussi à utiliser correctement le SQL ou qui ne connaissent pas toutes ses fonctionnalités (sans compter celles des SGBD comme la gestion du XML, du java, ...) et qui veulent réinventer la roue.
Et puis il existe des SGBDs qui gèrent très bien les grosses volumétries (Teradata, Netezza, ...)
Ou alors comme dit SQLPro pour créer leur nouveau standard propriétaire à des fins sans doute plus financières que techniques ...

[*alexandre*]

Tu résumes parfaitement mon opinion également

Cette histoire de NoSQL, ça sent les gens qui n'ont jamais réussi à utiliser correctement le SQL ou qui ne connaissent pas toutes ses fonctionnalités (sans compter celles des SGBD comme la gestion du XML, du java, ...) et qui veulent réinventer la roue.
Et puis il existe des SGBDs qui gèrent très bien les grosses volumétries (Teradata, Netezza, ...)
Ou alors comme dit SQLPro pour créer leur nouveau standard propriétaire à des fins sans doute plus financières que techniques ...

Le seul outil évolué qui correspond au demande des nouveaux développements (donc agé de moins de 6 ans est terracoda tout le reste ce n'est que du relationel pure et inadpaté au nouveau développement)

Je comprend votre problème vous n'avez pas compris l'utilisation des ORM alors le NO SQL mouvemennt je doute fortement que vous le compreniez mieux

On doit encore de nos jours lutter avec des ancètres qui veulent faire des requêtes sql dans un ORM alors que ca ne doit être que du code Java adaptable sur n importe quelle base sans aucune modification du code des DAO

[Keihilin]

Cette histoire de NoSQL, ça sent les gens qui n'ont jamais réussi à utiliser correctement le SQL ou qui ne connaissent pas toutes ses fonctionnalités

Là où ça devient très amusant, c'est que je connais pas mal de gens qui utilisent exactement le même argumentaire :

"Cette histoire de SQL, ça sent les gens qui n'ont jamais réussi à utiliser correctement COBOL avec DB2 ou qui ne connaissent pas toutes ses fonctionnalités et les merveilles de l'accès natif"

Je comprend votre problème vous n'avez pas compris l'utilisation des ORM alors le NO SQL mouvemennt je doute fortement que vous le compreniez mieux

[OWickerman]

En tout cas, merci pour ce thread, j'ignorais qu'il y avait des technologies autres que les sgbdr avec langage sql pour gérer ses données. Je vais de ce pas m'informer dessus.

[atc666]

Les adversaires de SQL multiplient les actions de protestation contre ce qu’ils appellent « la tyrannie » exercée par SQL dans l’univers de la gestion des bases des données

je sais pas toi mais moi quand je lit la première phrase de l'article j'ai du mal a trouver que c'est pacifiste.

[pseudocode]

je sais pas toi mais moi quand je lit la première phrase de l'article j'ai du mal a trouver que c'est pacifiste.

Certes, le premier post est un peu agressif.

Mais si on lit le message de présentation du meeting nosql:

This meetup is about "open source, distributed, non relational databases".

Have you run into limitations with traditional relational databases? Don't mind trading a query language for scalability? Or perhaps you just like shiny new things to try out? Either way this meetup is for you.

C'est nettement moins agressif.

[Xyphis]

Mon avis sur la problématique de base :

SQL est, à mon avis (et ça n'engage que moi), critiqué en tant que standard et non en tant que technologie ou valeur commerciale.

Je m'explique : quelqu'un a-t-il déjà eu, comme moi, la curiosité de lire la description du standard qu'est SQL ? (disponible sur www.iso.org mais prévoyez un week-end pour tout lire ^^). Eh oui... des pages et des pages... des ajouts faits ici et là, des cas particuliers...

La question que je me pose depuis est : "Pourquoi tout cela est-il si complexifié ? Pourquoi ne pas reprendre du début sur de bonnes bases ?" Eh bien voila, c'est ce que semble vouloir faire NoSQL, pour pallier aux limitations actuelles de SQL. Et j'avoue que SQL n'est pas intuitif... certains termes sont utilisés de manière tout à fait différente que ce que suggère leur nom et j'en passe...

On parlait d'incompétence... Et dites-moi, ne serait-ce pas la force de l'habitude qui vous fait vous sentir si à l'aise ? Personnellement j'ai eu beaucoup de mal à bien manipuler la syntaxe SQL. "L'incompétence", c'est plus facile de traiter d'incompétent quelqu'un qui utilise un langage plus complexe (d'ailleurs, à ce qu'il me semble, on ne programme plus en assembleur... incompétence ? je pense qu'ici c'est la même chose). Un standard plus léger permettrait de faire plus vite et plus efficacement ce qu'on fait déjà (de même qu'on utilise du java (ou autre langage oo) pour faire plus vite et plus efficacement ce que l'on concevait avant en langage assembleur).

[Jester]

Le problème de SQL est ses limitations. Une requête devient vite longue et franchement incompréhensible. C'est beaucoup trop verbeux avec beaucoup de répétitions (catastrophiques quand on ne met à jour qu'une partie de la requête au lieu de toutes les occurrences, pas forcément évident sur des requêtes de 400 lignes). Il faut deux select from dual pour créer une simple table de 2 lignes. On préfèrerait pouvoir faire un truc du genre {[id, name], [1, "John"], [2, "John2"]} pour définir une telle table temporaire.

Il y a aussi des problèmes d'usage, tout mettre en majuscule c'est contre-ergonomique.

NoSQL je dirais que c'est pire. Se baser sur le système de fichier et des programmes UNIX ... Au moins ce sera beaucoup moins verbeux mais incompréhensible.