Discussion :

[el_slapper]

Mais je suppose que ta femme est infirmière, secrétaire, caissière ou avocate, voir mère au foyer, pas informaticienne

...artiste peintre... mais bon, sur le fond, ça change pas grand chose.

Dans la mesure où ton boulot c'est l'informatique, t'es censé être callé sur l'info, du moins dans ton domaine... Ca me fait penser au types qui "connaissent" 36 langages, mais en fait n'en maitrise aucun...
Bref, t'as des gens qui sont chimistes et non pas mathématiciens, mais qui doivent tout de même connaître un minimum les maths pour faire correctement leur travail...

D'accord sur la première partie. Mais ce que je constate, c'est que nous pratiquons un métier extrêmement exigeant. Que tout le monde n'a pas la fibre pour faire ça. Seulement, les gens qui ont la fibre ne sont pas assez nombreux pour faire tout ce qu'il y a à faire. Donc on est obligé de recruter des gens au potentiel moins élevé(en info, ils peuvent être très forte) pour quand même faire le boulot.

Il ne faut évidemment pas leur confier les clefs de l'architecture, mais pour le reste ils peuvent se débrouiller - pour peu qu'on exige pas d'eux des choses du niveau des superbêtes.

C'est un peu comme Vista quoi, 85% des critiques sont infondés et émises par des personnes qui ne savent pas s'en servir / font n'importe quoi dessus.

Exemple parfait de ce que je veux dire : Vista, c'est destiné à 90% de la planète(le reste étant constitué d'Applistes et de Linuxiens, l'élite, quoi), et pas les plus doués. Si 85% des gens qui s'en servent s'en plaignent(ça fait 76,5% de la population mondiale), c'est que Vista a été mal pensé, et reste inaccessible à sa vraie cible.

J'ai une voiture. Je sais la conduire, pas très bien, mais ça suffit, car son interface est simple. Par contre, ne me demande pas de conduire un char. Non seulement je n'ai pas la formation, mais vu mes reflexes et ma vue, JAMAIS je n'arriverais à conduire ce truc là.

Vista, c'est comme une voiture : ça doit être accessible à tout le monde, parceque tout le monde a besoin d'un ordinateur.

SQL(enfin utilisé au summum de sa puissance, n'importe qui peut faire un SELECT simple), en informatique, c'est le Leclerc. Super-performant, mais réservé à une élite. Or on a des gens tout juste capables de conduire des camions(c'est toujours plus que les voitures), à qui on demande juste de transporter du matos. Leur foutre un Leclerc dans les pattes(du SQL super-utilisé), c'est donc, à mon sens, une mauvaise idée.

Bref, j'arrête le troll, et je vous laisse juste une petite histoire (descendre un peu pour la trad en anglais) :p

Très belle histoire, mais je ne vois pas le rapport : des gens moins doués, peuvent, sur des technologies moins exigeantes, faire un travail très propre. et, au final, apporter plus de valeur ajoutée que le super-expert qui sort la méga-solution de la mort qui tue, mais qui bâcle son boulot comme ton exemple Chinois.....

[Shirraz]

Très belle histoire, mais je ne vois pas le rapport : des gens moins doués, peuvent, sur des technologies moins exigeantes, faire un travail très propre. et, au final, apporter plus de valeur ajoutée que le super-expert qui sort la méga-solution de la mort qui tue, mais qui bâcle son boulot comme ton exemple Chinois.....

C'était pour le coté "ok, il y a des incompétent mais c'est pas grave, tant que ça marche c'est "chabuduo", c'est pareil"

[Lpu8er]

Sinon, pour ceux qui prônent les bases de données XML, j'ai une question simple:

Quelle place physique prend un base de données en XML, comparée aux moteurs de stockage accédés via SQL ?

C'était sûr que des débats comme cela allaient être lancés, soit dit en passant, vu le nombre de différents SGBDR actuels, par rapport aux normes établies.
Comme cela a été dit maintes fois, je pense qu'il ne faut pas prôner NoSQL à tout prix. L'utilisation d'un outil dépend du but, chose qui est trop souvent oubliée...

[SQLpro]

Pour ce qui est de bases XML, mon expérience est la suivante :
environ 2,5 à 6 fois plus de place au niveau du volume des données, pour les mêmes informations.
environ 4 à 20 fois plus lente en requêtes (INSERT, UPDATE, DELECT et SELECT).

A +

[Tommy31]

Pour ce qui est de bases XML, mon expérience est la suivante :
environ 2,5 à 6 fois plus de place au niveau du volume des données, pour les mêmes informations.
environ 4 à 20 fois plus lente en requêtes (INSERT, UPDATE, DELECT et SELECT).

Faut en dire un peu plus. Quelle bd xml native et quels tests ?

[Erwy]

Faut en dire un peu plus. Quelle bd xml native et quels tests ?

Ca serait assez intéressant en effet.

environ 2,5 à 6 fois plus de place au niveau du volume des données, pour les mêmes informations.

Les même informations ?
L'intérêt du XML c'est sa forme arborescente non figée pas l'arbre binaire obligatoire avec une profondeur maximale de 3 ou la table html;
Type de donnée extrèmement désagréable à stockr sous forme relationnel.

Si le test consiste à stocker de la table dans du XML alors je ne vois pas l'intérêt et il vaut mieux rester sur du relationnel.
Par contre , aujourd'hui et sans doute dans l'avenir le volume XML est en effet plus important (même si quelques technos travaillent sur du xml 'compressé') le format est verbeux, mais nettement plus parlant: ne pas oublé que l'un des objectif du XML est de rester compréhensible pour l'être humain avec un simple éditeur de texte.

En passant sur le XML "natif" dans les sgbdr auquel fait référence ton article, je ne peux parler que pour Oracle que je pratique avec trop d'assiduité à mon gôut mais cela me fait doucement rigoler.
A part la capacité de stocker le XML il ne faut pas trop en demander sur le reste (typage ,schéma, transformation, acces , fragment....)
Au mieux c'est une usine à gaz avec des performances risibles et des outils qui ne sont même pas à la norme (et ca fait un moment que ça dure sans amélioration notable)....
Hors utilisé du XML sans pouvoir utiliser les technos associées de typage ou d'extraction correctement c'est en perdre 80% de l'intérêt.

[B.AF]

Ca serait assez intéressant en effet.



Les même informations ?
L'intérêt du XML c'est ça forme arborescente non figé pas l'arbre binaire obligatoire avec une profondeur maximale de 3 ou la table html) .
Type de donnée extrèmement désagréable à stocké sous forme relationnel.

Si le test consiste à stocker de la table dans du XML alors je ne vois pas l'intérêt et il vaut mieux rester sur du relationnel.
Par contre , aujourd'hui et sans doute dans l'avenir le volume est plus important (même si quelques technos travaillent sur du xml 'compressé') le format est verbeux, mais nettement plus parlant ,ne pas oublé que l'un des objectif du XML est de rester compréhensible pour l'être humain avec un simple éditeur de texte.

En passant sur le XML "natif" dans les sgbdr auquel fait référence ton article, je ne peux parler que pour Oracle que je pratique, mais cela me fait doucement rigolé.
A part la capacité de stocker le XML il ne faut pas trop en demander sur le reste (typage ,schéma, transformation, acces , fragment....)
Au mieux c'est une usine à gaz avec des performances risibles et des outils qui ne sont même pas à la norme (et ca fait un moment que ça dure sans amélioration notable)....
Hors utilisé du XML sans pouvoir utiliser les technos associés de typage ou d'extraction correctement c'est en perdre 80% de l'intérêt.

Je suis assez d'accord avec toi, au sens où je me suis déjà battu avec une description très riche (FpML pour ne pas la citer), et en dehors d'une base objet ou d'un NXD, point de salut.

Pour les comparaisons en select, insert et autres, je crois qu'on ne parle de la même chose en fait.

Forcémment, entre stocker un fichier XML ou faire un select en XML, ce n'est pas le même usage ni la même recherche.

Clairement au vu de l'usage, j'aurai plus tendance à comparer le nxd a l'odb qu'au rdb. Sachant que le nxd apporte en plus l'api d'exploitation.

Par rapport à la norme que je cite ci dessus, pas un seul SGBD n'est capable de la contenir proprement (maintenance, perfs...). Bref, ça demande à ré-inventer une roue qui existe déjà.

[Rapha222]

Je suis assez d'accord avec toi, au sens où je me suis déjà battu avec une description très riche (FpML pour ne pas la citer), et en dehors d'une base objet ou d'un NXD, point de salut.

Pour les comparaisons en select, insert et autres, je crois qu'on ne parle de la même chose en fait.

Forcémment, entre stocker un fichier XML ou faire un select en XML, ce n'est pas le même usage ni la même recherche.

Clairement au vu de l'usage, j'aurai plus tendance à comparer le nxd a l'odb qu'au rdb. Sachant que le nxd apporte en plus l'api d'exploitation.

Par rapport à la norme que je cite ci dessus, pas un seul SGBD n'est capable de la contenir proprement (maintenance, perfs...). Bref, ça demande à ré-inventer une roue qui existe déjà.

Je pense que SQLpro voulais juste signaler que dans les cas d'utilisation des SGBDR (forte capacité de stockage, nombreuses demandes de recherche, accès simultanées et distribution des tâches sur différentes machines, gestion des transactions, ...), le XML et les technologies basées dessus sont tout simplement inapplicable. Le XML ne concurrence en aucun cas les SGDBR, contrairement à ce que veulent faire croire les membres des groupes anti-SQL.
De même, je vois mal remplacer le xHTML, XAML ou XMPP par des bases SQLite
L'idée de remplacer SQL par XML (sauf cas particuliés) est totalement infondée et est basée sur une méconaissance des deux technologies.

[B.AF]

Je pense que SQLpro voulais juste signaler que dans les cas d'utilisation des SGBDR (forte capacité de stockage, nombreuses demandes de recherche, accès simultanées et distribution des tâches sur différentes machines, gestion des transactions, ...), le XML et les technologies basées dessus sont tout simplement inapplicable. Le XML ne concurrence en aucun cas les SGDBR, contrairement à ce que veulent faire croire les membres des groupes anti-SQL.
De même, je vois mal remplacer le xHTML, XAML ou XMPP par des bases SQLite
L'idée de remplacer SQL par XML (sauf cas particuliés) est totalement infondée et est basée sur une méconaissance des deux technologies.

Le XML reste en mon sens un standard bien plus méconnu que le sql.
Combien de fois j'ai vu des gens faire du xml en se contentant de faire des balises et de mettre un header, pas de XSD , rien....

Quand tu parles de SQL Lite, tu remarqueras que ce qui poserait problème dans les formats que tu nommes, c'est leur modèle abstrait, ex : dependency properties du XAML. Là où avec un XSD et un bon éditeur, tout devient simple, faire cela dans un SGBD relève du cauchemard.

Mais je suis d'accord avec toi que le No SQL c'est aussi radical que tout SQL.

D'où mon concept de fonds : utiliser la bonne techno pour faire le bon job.

Prenons un ex simple :

Je suis confronté aujourd'hui à une situation où je dois créer un soft qui doit pouvoir fonctionner :
- En workstation avec base embarquée
- En Client / serveur avec base open source
- En 3 tiers avec un serveur d'application + BDD
Le tout, sur modification de paramètres applicatifs...

La question de l'accès aux données est crucial, car je peux réussir à la faire cohérente dans 1, ou 2 scénarios et échouer le 3éme.

Donc je me pose des questions en ce moment sur des alternatives, sachant qu'en outre SQL Lite...bof...Même si pour 1 il fait le job..

[Erwy]

Je pense que SQLpro voulais juste signaler que dans les cas d'utilisation des SGBDR (forte capacité de stockage, nombreuses demandes de recherche, accès simultanées et distribution des tâches sur différentes machines, gestion des transactions, ...), le XML et les technologies basées dessus sont tout simplement inapplicable.

Ah bon ???
Tu ne confondrais pas fichier XML et SGBD XML par hasard ?

Pour les très grosses volumétries :
Wikipédia est un des utilisateurs de xml compressé(dont je parlais precedemment) à ma connaissance mais là les outils ne sont pas normé et ce n'est pas du sgbd

Le XML ne concurrence en aucun cas les SGDBR, contrairement à ce que veulent faire croire les membres des groupes anti-SQL.

Je rappelle, pour ceux qui n'aurait pas lu, qu'une des choses amusantes était qu'aucun représentant de SGBD XML n'était présent à cette manifestation .
Donc je ne sais pas ce que veulent faire croire les anti-sql mais ils ne semblent pas beaucoup compter de partisans XML

L'idée de remplacer SQL par XML (sauf cas particuliés) est totalement infondée et est basée sur une méconaissance des deux technologies.

Cas particuliers oui mais ne pas confondre avec rare.
Comme déjà dit , ces bases sont déjà utilisé depuis un moment dans le contexte documentaire et s'y trouvent très bien, surtout s'y on tient compte de leur jeunesse relative(6-7 ans max ?) par rapport à d'autres technologie

[atc666]

Ce qui me depasse c' est la "rage" des antisql je ne comprend pas pourquoi reniés l'intèrêt de celui.
mais bon je pense aussi que la rage de Sqlpro ( que je remercie pour tous ses tuto sur le sql qui m ont permis de comprendre et d' apprendre le sql et auquel je fait encore souvent appel pour me souvenir d'un terme ou d'une syntaxe etc) est au moins aussi exagerée. comme pas mal d'entre vous je pense qu'il doit y avoir plusieurs alternatives a utiliser selon les besoins exacts et précis de l'application a faire tourner.
Il serai aussi inadéquat de vouloir utiliser la dernière version d' oracle pour gere sa liste de course hebdomadaire , que de vouloir utiliser un seul fichier texte pour gerer l'état civil des états unis. ce qui revient a dire , il me semble que chaque type de "base de donnée" a son utilité si elle peut remplir les fonctions dont nous avons besoins au moment ou nous en avons besoin et cela au meuilleur cout ( argent, temps, sécurité).

Pour ce qui est de l incompètence de certain , je parie que ceux ci sont venu a l'info uniquement parce qu' a une époque celle ci était très a la mode et surtout nourrissait bien son homme. Je me demande si la solution proposée par certain n' est pas un peu dangereuse .
je m'explique :
Dans pas mal de pays , on a vu une baisse des reçus en fin de secondaires , résultats on as allégés les programmes d'études. ca as permis d'avoir par après un mieux coté statistique , mais ca a aussi baissé le niveau des "promus". Les quels ont eux plus de mal a suivre je parie dans le niveau supérieur. Effet pervers ?
Ne risque t'on pas a force de rendre plus "facile" les choses de voir un nivellement par le bas ?
Déja que nos télévisions pratiquent souvent ce nivellement par le bas en rendant les gens accros de séries plus infantilisantes les unes que les autres.
Permettre à n'importe qui de faire n'importe quoi qu'il soit doué ou pas, qu'il soit vraiment motivé ou pas, ne pourrait t'il pas à la longue creuser encore ce gouffre entre les gens "intelligents" et les autres. Tout en rendant ceux de la première catégorie de plus en plus rare ???

Maintenant, je dirai encore 2 choses :
la première : on est toujours le con d'un autre , il y a toujours quelqu'un qui tot ou tard sera meuilleur ou connaitra mieux un sujet que vous , et qui finira par vous prendre pour son "con"

La seconde : Ne pas etre un super pro dans tel ou tel domaine cela ne veut nullement dire qu'on est moins intelligent qu'un autre, chacun de nous a ses dons qu'il a eu ou pas la chance de découvrir. Et heureusement qu'il en est ainsi car sinon, le monde serait bien triste , remplis de "clones" ayant les mêmes idées que nous sur tout et ayant les mêmes compètances. pensez y le jour ou votre plombier venu pour reparer le robinet de votre douche , passant devant votre ordinateur vous dira "Je ne comprend rien a ces saletés d'engins. Comment pouvez vous passez des heures devant ces horreurs ? ca ne vous fait pas mal à la tête ?" . allez dans la sdb avec lui et regardez le travailler sur votre robinet , et je suis sur que la plupart d'entre vous n'y comprendront rien non plus .

ps: question de noobs , un peta par rapport a un giga ou un terra ca fait quoi ?

[benwit]

un peta par rapport a un giga ou un terra ca fait quoi ?

giga < téra < péta

Avec un facteur de 1000 à chaque fois si on parle des préfixes du système international d'unités

Avec un facteur de 1024 (2 puissance 10) pour les préfixes binaires.

[pseudocode]

Ce qui me depasse c' est la "rage" des antisql je ne comprend pas pourquoi reniés l'intèrêt de celui.

? Quelle rage ?

Le communauté "nosql" fait simplement la promotion des systèmes de gestion de bases de données non-relationnelles (NRDBMS), en argumentant que se passer des avantages du "relationnel" permet également de s'affranchir des contraintes des SGBDR

[romain_schlick]

Pour les personnes interessés sur le Big Table de Google et plus particulièrement le datastore de Google App Engine. Je viens de rédiger un article sur le sujet: article

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

[benwit]

Pour les personnes interessés sur le Big Table de Google et plus particulièrement le datastore de Google App Engine. Je viens de rédiger un article sur le sujet: article

Merci.
J'avais commencé à regarder les papers de Google mais c'est sympa de faire une synthèse dans la langue de Molière.
J'attends la suite avec impatience ...

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

[B.AF]

Je crois surtout que le problème de fonds est ue le SGBD est employé pour tout et rien.

En soit heureusement qu'il y a des alternatives. Après, de toutes façons, c'est déjà très provoc de dire NoSQL.