Discussion :

[gregory.broissard]

Non pour moi Google a je pense du évaluer le besoin et a réalisé la solution technique pour son besoin spécifique.

je n'ai pas le meme besoin que Google donc sa solution n'est pas forcément adaptée.

Car il faut reconnaitre que les besoins mentionnés sont très très spécifiques...

La démagogie c'est de dire que la solution d'un tel ou d'un tel est mieux que SQL et va le remplacer juste parce qu'elle répond à leur besoin spécifique. Ca c'est démagogique.

[pseudocode]

Non pour moi Google a je pense du évaluer le besoin et a réalisé la solution technique pour son besoin spécifique.

je n'ai pas le meme besoin que Google donc sa solution n'est pas forcément adaptée.

C'est certain. Ce genre de techno n'est pas fait pour gérer un carnet d'adresse de téléphone portable.

Car il faut reconnaitre que les besoins mentionnés sont très très spécifiques...

Et bien, je remarque que les entreprises produisent toujours plus de données électroniques (documents, mails, compta, prévisions, ventes, stocks, ...), et que toutes ces données doivent être conservées, consolidées et traitées.

Le volume est tel qu'un seul SGBD est rarement suffisant. On a souvent un serveur SQL par "source" de données (GED, Achat, GPAO, ...), et parfois des serveurs SQL contenant les données "consolidés", ce qui implique des réplications, agrégations, et traitements journaliers pour construire cette consolidation.

Finalement, on n'est pas si loin des problématiques de Google : le volume de données devient tellement important que l'on est face à deux choix:
- Ajouter des serveurs SQL et créer/maintenir des jobs de Replications/Traitements.
- Changer de techno afin d'avoir une seule grosse base de données.

La démagogie c'est de dire que la solution d'un tel ou d'un tel est mieux que SQL et va le remplacer juste parce qu'elle répond à leur besoin spécifique. Ca c'est démagogique.

Entièrement d'accord. Mais le mouvement NoSQL ne prône pas du tout le remplacement à tout prix du SQL. Il ne fait que dénoncer l'approche actuelle : l'utilisation du SQL partout car c'est "la" solution à tous les problèmes de gestion de données.

S'il y a démagogie, elle est dans le camps des pro-sqlistes.

[wiztricks]

Souvenez vous il y a quelques années, les serveurs applicatifs CICS sur mainframes traitaient des milliers de clients simultanés avec la puissance d'un Pentium 1ere génération à 100Mhz !
Maintenant avec toutes les technologies modernes, certes l'interface graphique est plus sympa qu'un écran 3270, mais il faut des débauches de puissance pour faire tourner des applications avec des clusters, des Go de RAM, etc...

Mais bon de toute facon, comme ca a été mentionné déjà, c'est ridicule d'essayer de songer à tuer SQL... C'est un peu comme ceux qui voulaient enterrer Cobol il y a 15/20 ans, ils n'ont jamais réussi parce que c'etait efficace. C'est pareil pour le standard SQL...

D'ailleurs, quand je vois encore le volume de données qu'il reste dans les grosses boites dans des bases hiérarchiques en IMS/DL1...

C'est ce qu'on appelle le 'legacy'. Ce n'est pas péjoratif: le 'legacy' étant ce qui fonctionne (n'en déplaise à certains).

Maintenant sans forcément jeter le bébé avec l'eau du bain, force est de constater que l'efficacité de SQL repose sur une certaine structuration des données...

Et que nous avons de plus en plus à traiter des données non-structurées.
Le débat porte donc sur:

• faire évoluer SQL pour qu'il prenne en compte ce type de données (et est-ce que cela à un sens),
• marier SQL a autres solutions?
• faire autre chose?

Tant que vous n'avez pas à vous poser sérieusement la question, vous êtes heureux... Dans le cas contraire, il faut rester pragmatique et construire une solution adaptée aux besoins réels qui

• ne vous scotche pas trop à des technologies particulières,
• soit la plus maîtrisable en fonction des savoir-faire,
• ait de bonnes marges d'évolutions

-W

[wiztricks]

Entièrement d'accord. Mais le mouvement NoSQL ne prône pas du tout le remplacement à tout prix du SQL. Il ne fait que dénoncer l'approche actuelle : l'utilisation du SQL partout car c'est "la" solution à tous les problèmes de gestion de données.

S'il y a démagogie, elle est dans le camps des pro-sqlistes.

Le propre d'un changement de paradigme est de partir sur une feuille blanche pour pousser la logique sans s'embarrasser de l'existant.

Le patrimoine des bases de données SQL est tel qu'il paraît préférable d'étendre les possibilités des SGDB actuels plutôt que de tout reconstruire.

La solution s'il y en a une reste à construire et en attendant, les hérauts des différents camps défendent leur bout de gras avec des arguments qui relèvent plus de la rhétorique classique que d'une réelle problématique technique.

Quelque soit l'issue du débat, SQL ne disparaîtra pas du jour au lendemain pas plus que n'ont disparu les bibliothèques et les applications écrites en Cobol ou en Fortran...

Finalement, on n'est pas si loin des problématiques de Google : le volume de données devient tellement important que l'on est face à deux choix:
- Ajouter des serveurs SQL et créer/maintenir des jobs de Replications/Traitements.
- Changer de techno afin d'avoir une seule grosse base de données.

Si nous débattons ici, c'est qu'il y a un vrai problème.
Est ce que la solution est une seule grosse base de données? Peut être.
Si c'est votre point de vue, le futur est peut être déjà là: voir OpenSpaces.org
Note: Pour ma boîte, çà ne le fait pas... mais je suis sûr que çà peut répondre à toute une classe de besoins de ce type.
-W

[Keihilin]

Et bien, je remarque que les entreprises produisent toujours plus de données électroniques (documents, mails, compta, prévisions, ventes, stocks, ...), et que toutes ces données doivent être conservées, consolidées et traitées.

force est de constater que l'efficacité de SQL repose sur une certaine structuration des données...

Et que nous avons de plus en plus à traiter des données non-structurées.

Deux phrases qui résument assez bien le problème...

Je ne vais pas faire un exposé ici, mais je vous invite à chercher quelques ressources sur les travaux actuels concernant le "web sémantique" (machine-tags, rdf, skos, etc...) car c'est, à mon avis, un domaine qui est à l'origine de nouveaux besoins pouvant conduire à la remise en question du modèle relationnel et par extension de SQL.

[alex.]

Le propre d'un changement de paradigme est de partir sur une feuille blanche pour pousser la logique sans s'embarrasser de l'existant.
...

force est de constater que l'efficacité de SQL repose sur une certaine structuration des données

Whitepaper produit par Google

Bigtable: A Distributed Storage System for Structured Data

[wiztricks]

Whitepaper produit par Google

Si vous allez faire un tour sur Hbase (qui est une version OpenSource de bigtable) vous trouvez [extraits]

When HBase Shines

One place where HBase really does well is when you have records that are very sparse. This might mean un- or semi-structured data. In any case, unlike row-oriented RDBMSs, HBase is column-oriented, meaning that nulls are stored for free. If you have a row that only has one out of dozens of possible columns, literally only that single column is stored. This can mean huge savings in both disk space and IO read time.

Another way that HBase matches well to un- or semi-structured data is in its treatment of column families. In HBase, individual records of data are called cells. Cells are addressed with a row key/column family/cell qualifier/timestamp tuple. However, when you define your schema, you only specify what column families you want, with the qualifier portion determined dynamically by consumers of the table at runtime. This means that you can store pretty much anything in a column family without having to know what it will be in advance. This also allows you to essentially store one-to-many relationships in a single row! Note that this is not denormalization in the traditional sense, as you aren’t storing one row per parent-child tuple. This can be very powerful - if your child entities are truly subordinate, they can be stored with their parent, eliminating all join operations.

Et n'espérez pas que l'API ressemble à du SQL, voir getting started
Bon d'accord, cela fonctionne au dessus de Hadoop et... le matelas pourra sans doute être épaissi pour que... mais ce n'est pas l'urgence.

Si vous voulez voir une solution qui parle SQL au dessus d'un Hadoop, j'avais déjà mentionné HadoopDB
-W

[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*]

Oui, en moins bien.
Google a dévellopé un outil qui permet, dans l'état actuel du hardware, de gérer des volumes de données énormes.

Comme "c'est à la mode" on va le voir s'utiliser avec des bases de quelques Giga ou Tera de façon complétement inutile, sans se soucier des coûts de développement et d''architecture et d'expertise induits.

C'est, amha, avant tout une technique logiciel qui permet de palier à une faiblesse momentanée du Hardware (ce n'est pas le cas de sgbd/r, cf les travaux de Codd).

C'est des soucies d'expertise en moins donc une diminution de coûts peut être la manière de stockage des données sur tes peta bytes de données de toutes facon vous ne savez pas les gérez.

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

[jmguiche]

Par exemple si j'ai une table de ventes et que je veux savoir le chiffre d'affaire par heures (agrégation simple). Certaines heures, je n'ai pas de ventes, mais je veux que ça me retourne zéro au lieu d'une ligne manquante. Ce que j'utilise (c'est peut-être pas optimal mais j'ai pas encore vu mieux).

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
 
select heure, sum(prix) from (
  select 1 as heure from dual union select 2 as heure from dual ..... ) temps
  left outer join ventes on temps.heure = ventes.heure

Pour le with, j'entendais des versions d'oracle qui ne le comprennent pas, pas des personnes. je viens de trouver le CONNECT BY LEVEL qui semble aider dans ce cas (pur oracle par contre).




Amusant, car je n'ai pratiquement jamais vu du code SQL en minuscule. C'est un avis personnel mais je pense que les conventions de langages sont une bonne chose et influent sur l'utilisation.

Ce qu'il manque c'est principalement les variables et un système de macro. Quelques méthodes pour éviter les imbrications de select que je dirais cosmétiques. Je ne critique pas du tout les fondements du langage plutôt l'ergonomie.

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
 
select heure, sum(prix) from (
  select rownum fron vente where rownum <= 24) temps
  left outer join ventes on temps.heure = ventes.heure

[jmguiche]

Si votre première requête que vous faites sur cette page http://www.waldar.org/blog/200904/yo...like-analytics , ne vous semble pas verbeuse, alors oui, on ne va pas se comprendre.

J'ai dit mon impression sur le sujet. Après une impression c'est subjectif et vous pouvez en avoir un autre, dont vous ne nous avez pas encore fait part.

Tu as mieux et lisible quelquepart ?

[jmguiche]

... la possibilité de mise en clusters ne fonctionne pas avec du sql server, oracle ou autre sgbd ou demanderait l'utilisation de super calculateur ...

Ha bon ? Vous êtes sûr ?
Moi pas !

La mise en cluster d'oracle ça marche. Avec Sql Server aussi tres probablement.

le surcout (en licence) est largement amorti par les économies faites par un dev Thick DB par rapport à un Dev Java ou C# et les perfs sont meilleurs.

Pensez à vos clients !

[jmguiche]

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"

Ben moi, j'ai l'age et le vécu pour penser ça... (premiers travaux : cobol IDS2, ensuite Cobol DL/1).

Et ben non....

Et je pense que personne maitrisant Cobol / IDS ou Codasyl ET Les SGBD/R puisse penser cela.

Il est clair, qu'en fin 80, mettre plus de 50 users simultané sur un SGBD/R c'était risqué. La techno avait ses détracteurs. Mais depuis...

[jmguiche]

C'est des soucies d'expertise en moins donc une diminution de coûts peut être la manière de stockage des données sur tes peta bytes de données de toutes facon vous ne savez pas les gérez.

Ha parce que l'expertise sur les outils google, c'est pas cher et ca se trouve partout ? Ca c'est un scoop.

Et mes peta bytes, je suis comme 99,99% des informaticiens : je n'en ai pas. Je me moque donc pas mal de ne pas encore savoir les gérer avec du SQL !

Et il serait assez dommage d'employer une techno spécialisée dans le sujet des péta bytes et plutot moins bien pour tout le reste alors qu'on n'a pas de pétas bytes !

[pseudocode]

Ha bon ? Vous êtes sûr ?
Moi pas !

La mise en cluster d'oracle ça marche. Avec Sql Server aussi tres probablement.

le surcout (en licence) est largement amorti par les économies faites par un dev Thick DB par rapport à un Dev Java ou C# et les perfs sont meilleurs.

Pensez à vos clients !

Il faut comparer les fonctionnalités, le prix et la facilité de mise en oeuvre.

- Avec un SGBDR, on commence par acheter un serveur, genre Core 2/4 + disques SCSI 200Go en RAID 5 (pour la tolérance de panne). Et puis, lorsque les bases sont pleines, on rachète encore des disques en RAID 5. On arrête le serveur, on ajoute/configure le raid, et on étend les tablespaces. Et puis, quand c'est plein, on achète une baie SAN + disques. On arrête le serveur, on crée des nouveaux tablespaces sur la baie et on migre les données. Et puis, maintenant qu'on a un gros volume de données, c'est lent. On achète un deuxième serveur. On arrête le 1er serveur et on monte un cluster avec les 2 serveurs. etc. etc.

- Avec un truc genre BigTable, on commence par utiliser un PC "entrée de gamme" (c-a-d pentium 4 + disque 200Go) qu'on branche sur le réseau. On en prend un deuxième, on le branche aussi sur le réseau et on le configure en copie/backup (pour la tolérance de panne). Lorsque les bases sont pleines, on prend un 3ème PC, on le branche sur le réseau et on le configure en extension. idem avec un 4ème PC, 5ème PC, ... , 100ème PC ! Pas de problèmes de lenteur car plus de PC = plus de perf.

[Keihilin]

Et je pense que personne maitrisant Cobol / IDS ou Codasyl ET Les SGBD/R puisse penser cela.

Maîtriser, c'est le mot !

Mais pour maîtriser, encore faut-il être capable de sortir le nez de la technologie que l'on utilise depuis 20 ans et admettre la possibilité qu'une nouvelle façon de faire soit meilleure sur certains plans...

[Jester]

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
 
select heure, sum(prix) from (
  select rownum fron vente where rownum <= 24) temps
  left outer join ventes on temps.heure = ventes.heure

Merci, mais je pense qu'il vaut mieux rester verbeux plutôt que de faire des choses aussi crade. De plus ça ne résout pas tout les problèmes de référentiels. Enfin peut-être qu'il n'est pas utile de rester sur un problème.

Non je n'ai pas mieux, sinon je l'utiliserais. Ce débat me semble clos, une partie ici pense que SQL est déjà la perfection et qu'il n'y a plus besoin de rien changer. Moi je pense qu'il y a encore des choses à faire, c'est tout.

Pour la facilité de mise en oeuvre, je pense que plus de machines = plus de besoin d'administration = plus de problèmes. Notez que ça c'est pas mon problème, mais je suis pas sur que ce serait optimal à utiliser aussi.

[jmguiche]

Merci, mais je pense qu'il vaut mieux rester verbeux plutôt que de faire des choses aussi crade. De plus ça ne résout pas tout les problèmes de référentiels. Enfin peut-être qu'il n'est pas utile de rester sur un problème.

Non je n'ai pas mieux, sinon je l'utiliserais. Ce débat me semble clos, une partie ici pense que SQL est déjà la perfection et qu'il n'y a plus besoin de rien changer. Moi je pense qu'il y a encore des choses à faire, c'est tout.

Pour la facilité de mise en oeuvre, je pense que plus de machines = plus de besoin d'administration = plus de problèmes. Notez que ça c'est pas mon problème, mais je suis pas sur que ce serait optimal à utiliser aussi.

C'était un exemple sur le principe. Avec un poil d'imagination, on crée une table "Iteration" avec une colonne N numérique, qu'on remplis de nombres allant de 1 à autant que necessaire et on remplace :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

Select rownum from table where rownum <= X

par

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

Select N from Iteration where N <= X

Ca simplifie beaucouop de choses et c'est plutôt moins crade que des unions de dual !

Je ne sais toujours pas ce qu'est le problème des référentiels.

Je ne pense pas que grand monde pense que SQL c'est la perfection, mais pas mal de gens pensent, je crois, que SQL, sur le marché, il n'y a pas grand chose de mieux. SQL continue d'évoluer.