Discussion :

[_Xavier_]

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

Quand on veut programmer en Java on apprend le concept Objet, quand on veut faire du C on s'intéresse au procédural et pour le Sql on ne doit faire aucun effort alors que c'est à ce niveau qu'on manipule "des données", ce qu'il y a de plus sensible dans le système d'information.

[alex.]

Lu sur le BigTable de Google :

Les requêtes
Les requêtes sont écrites en JDOQL ou JPQL selon que l'on utilise l'implémentation JDO ou JPA. Il est possible de faire des jointures entre des entités appartenant au même groupe et de filtrer via des propriétés des entités parent et enfant.
Le data store gère les sélections, les filtres et les tris. Il est aussi possible de définir des plages (range) de résultat.
Cependant, oubliez les group by, les aggrégations, et les fonctions, ainsi que l'opérateur !=. Autre contrainte : il n'est possible de définir qu'un seul filtre d'inégalité par requête, et il faut impérativement ajouter la propriété filtrée comme première clause dans le tri.
import java.util.List;
import javax.jdo.Query;
// ...

Query query = pm.newQuery(FeedEntity.class);
query.setFilter("lastUpdateDate>= dateParam");
query.setOrdering("lastUpdateDate desc");
query.declareParameters("Date dateParam");
query.setRange(0,10);

List<FeedEntity> results = (List<FeedEntity>) query.execute(new Date());


GAE génèrent des index automatiquement pour chaque requête de l'application. Il est possible de créer ses propres index dans le fichier datastore-indexes.xml selon les besoins. Attention, les entités dont les propriétés ne sont pas indexées ou dont les propriétés n'existent pas seront ignorées par le data store.

À ce jour, Google ne fournit aucun outil pour visualiser et requêter le datastore en environnement de développement.
Cependant, dans l'interface d'administration du serveur fourni par Google, il est possible de requêter sur le datastore de production via le langage GQL (Google Query Langage) qui ressemble beaucoup à SQL.

Ils réinventent la roue ?

[*alexandre*]

J'avais rédigé un post qui parle de Hbase (Mais plus de Hadoop)

Voici un lien avec un example pour hbase :

http://wiki.apache.org/hadoop-data/a..._ets_clean.pdf

Et le lien du post sur Hadoop / HBase

http://www.developpez.net/forums/d76...lesystem-hdfs/

[jmguiche]

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.

Probablement, tu es sous oracle (DUAL).

Je constate au contraire qu'a fonctionnalité égale, une requete SQL est bien moins verbeuse, bien moins complexe et bien plus performante qu'un équivalent "SQL sous employé - outil de mapping R/O - surcouche objet".

Je ne comprend pas le coup de "2 accès à dual pour une table de 2 lignes".
Je suppose que tu connais "insert into ... values ..." ainsi que fort probablement "insert into ... select... where rownum < = 2" (et donc "create table as ... rownum <= 2")

Quand aux répétitions, je pense que tu connais aussi la clause WITH, qui permet de nommer une sous requette pour la référencer à plusieurs endroits.

Je pense que les autres SGBD "sérieux" ont la même chose ou l'équivalent à proposer.

Rien ne t'oblige a mettre dans ton code que des majuscules. Tu peux mettre des majuscules ou des minuscules ou tu veux. Je ne comprend pas non plus ta remarque sur "tout mettre en majuscules".

[jmguiche]

Lu sur le BigTable de Google :


Ils réinventent la roue ?

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

[Jester]

Je ne comprend pas le coup de "2 accès à dual pour une table de 2 lignes".
Je suppose que tu connais "insert into ... values ..." ainsi que fort probablement "insert into ... select... where rownum < = 2" (et donc "create table as ... rownum <= 2")

En fait c'est dans le cas où tu dois créer un référentiel avec lequel tu va faire une jointure externe.

Quand aux répétitions, je pense que tu connais aussi la clause WITH, qui permet de nommer une sous requette pour la référencer à plusieurs endroits.

Ça reste très verbeux et on a encore des oracle qui ne comprennent pas cette syntaxe.

Rien ne t'oblige a mettre dans ton code que des majuscules. Tu peux mettre des majuscules ou des minuscules ou tu veux. Je ne comprend pas non plus ta remarque sur "tout mettre en majuscules".

C'est la convention utilisé là où je travaille et il me semble utilisée dans 99% des cas il me semble. Et l'intérêt d'utiliser une convention collective dépasse les inconvénients de celle-ci.

[jmguiche]

En fait c'est dans le cas où tu dois créer un référentiel avec lequel tu va faire une jointure externe.



Ça reste très verbeux et on a encore des oracle qui ne comprennent pas cette syntaxe.



C'est la convention utilisé là où je travaille et il me semble utilisée dans 99% des cas il me semble. Et l'intérêt d'utiliser une convention collective dépasse les inconvénients de celle-ci.

Pour le premier alinéa, cela me semble un cas bien curieux et je ne le vois pas trop. Un exemple ?

Pour le second, personnelement je ne connais pas de moins verbeux a part quelques langages tres ésotériques et souvent illisibles. Un exemple de "répendu et plus efficace" ?
Quand a ceux qui ne savent pas, en 10 minutes de lecture de la doc, ils savent. Et s'ils n'ont pas la curiosité, à chaque nouvelle version de leurs outils, de voire les nouveautés, personne ne peut rien pour eux. Cela n'est en aucun cas à porter au discrédit de l'outil.

Pour le troisième, cela fait plus de 20 ans que je fais de l'Oracle, dans des dizaines d'entreprises, je n'ai vu cette convention qu'au tout début. Comme quoi les experiences ne se ressemblent pas ! De toute façon, là aussi, ce n'est pas à porter au discrédit de l'outil.

[*alexandre*]

Pour le troisième, cela fait plus de 20 ans que je fais de l'Oracle, dans des dizaines d'entreprises, je n'ai vu cette convention qu'au tout début. Comme quoi les experiences ne se ressemblent pas ! De toute façon, là aussi, ce n'est pas à porter au discrédit de l'outil.

c'est censé prouver quoi ? 20 ans dans les mêmes techno ca me ferait plus que ***** et ne serait en aucun cas un argument de vente mais me ferait au contraire du préjudice ... tu démontres en quelques lignes que tu n'as jamais voulu évoluer

Vous prenez les chercheurs pour des cons j'ai l'impression, si des firmes comme google, ibm, facebook, yahoo investissent dans la recherche et la conception d'outils plus adapaté pour un usage massif d'accès aux bases ce n'est pas emmerder les puristes des vieux systèmes mais plutot dans un soucie d'amélioration et d'évolution des contraintes

Si on vous dit que les vieux systèmes ne sont pas adaptés ....

[jmguiche]

c'est censé prouver quoi ? 20 ans dans les mêmes techno ca me ferait plus que ***** et ne serait en aucun cas un argument de vente mais me ferait au contraire du préjudice ... tu démontres en quelques lignes que tu n'as jamais voulu évoluer

Vous prenez les chercheurs pour des cons j'ai l'impression, si des firmes comme google, ibm, facebook, yahoo investissent dans la recherche et la conception d'outils plus adapaté pour un usage massif d'accès aux bases ce n'est pas emmerder les puristes des vieux systèmes mais plutot dans un soucie d'amélioration et d'évolution des contraintes

Si on vous dit que les vieux systèmes ne sont pas adaptés ....

Cela veut dire que depuis 20 ans, je fais de l'oracle, en général sur des applications pas simples, et elle fonctionnent. Cela ne veux pas dire que je n'ai pas fais ou dirigé, autour de l'oracle, du L4G, du Java, du .NET, du C++ et autres.

Je ne vois rien dans ce que tu dis qui soit un argument autre que "comme c'est neuf, c'est mieux". C'est amha, une argumentation faible.

Le seul qui démontre quelque chose en quelques lignes, ici, c'est toi : ta capacité à porter des jugements à l'emporte pièce et une curieuse pudeur qui t'interdit d'écrire le mot chier et pas le mot con.

Les gens de chez google et yahoo travaillent en effet sur des systèmes dont le but et de gérer des péta octets et alors ? Qui fait ça ici ? Ceux là peuvent juger du bien-fondé ou non de ces technos. Moi je ne gère modestement que des teras. Les chercheurs de ces boites ne sont pas des cons. Ils répondent à la question que le marketing leur pose.

Je ne suis pas un puriste des vieux systèmes. Seulement quelqu'un qui connait les deux mondes, celui du SGBD et des thick databases, et celui de l'objet.

J'ai comparé les deux approches (dans l'objet, je reconnais que je ne dévellopait pas, je dirigeait les projets assez loin de la technique, j'avais par contre une bardée d'experts internes et consultants d'éditeurs). C'est par retour d'experience que je me suis fait mon opinion. J'ai pu comparer le développement du même service fonctionnel par différentes techniques.

Je me moque éperdument du génie de tel ou tel chercheur ou de la beauté de telle ou telle technique : je fais de l'informatique de gestion. Dans les entreprise, c'est un centre de coût. Ce qui compte c'est le coût de l'investissement, le coût de possession, le service rendu, la fiabilité. Ce sont les seuls critères de comparaisons qui compte.

[*alexandre*]

Hello,

Je me suis un peu emporté, je ne critique pas les vieux systèmes en fait je les utilise dans le développement de mes applications quotidiennement sauf dans le cadre de projet de recherche ou les performances, la possibilité de mise en clusters ne fonctionne pas avec du sql server, oracle ou autre sgbd ou demanderait l'utilisation de super calculateur ... et ca franchement les clients n'en ont pas les moyens

[Waldar]

Je pense que toute cette discussion est relativement inutile.

Les bonnes solutions (meilleur compromis performance / coût / fonctionnalités / support / R&D) sont choisies par le marché.

Les SGBDR et SQL ont fait leur trou car ils remplissent leur rôle.

Ils ne sont pas adaptés à Google ? Pas de soucis, Google invente sa solution qui convient, sur un secteur très particulier. Est-ce que Google a eu raison ? Oui.

Est-ce que ça remet en cause les dizaines d'années d'implémentation des bases de données dans d'autres contexte d'exploitation ? Non.

Il n'y a pas une solution à un problème, il y a plusieurs solutions à plusieurs problèmes et je ne vois pas ce qui est gênant, il y a de la place pour tout le monde.

[wiztricks]

Je n'ai rien à dire sur le débat, il restera ouvert pendant longtemps encore.
Mais, ayant à faire un peu de veille techno sur ce sujet, et pour ce qui voudraient voir ce que pourrait être le 'futur', deux pistes à suivre:

• HadoopDB : http://www.h-online.com/open/HadoopD...--/news/113822
• YAGO : http://www.mpi-inf.mpg.de/yago-naga/yago/

Bons voyages
- W

[Jester]

Pour le premier alinéa, cela me semble un cas bien curieux et je ne le vois pas trop. Un exemple ?

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

Pour le troisième, cela fait plus de 20 ans que je fais de l'Oracle, dans des dizaines d'entreprises, je n'ai vu cette convention qu'au tout début. Comme quoi les experiences ne se ressemblent pas ! De toute façon, là aussi, ce n'est pas à porter au discrédit de l'outil.

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.

[*alexandre*]

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.

Pourquoi ne codes tu pas tes requêtes en Java vu que tu utilises Oracle ou C# si tu utilises SQL Server

Le sql est les implémentations propriétaires ne sont pas assez bien développper ...

[Waldar]

Jester, si vous travaillez sur Oracle 6 je vous comprends. Mais depuis il y a eu quelques releases et vous devriez lire la documentation et le forum Oracle, vraiment.

Vous critiquez vos propres lacunes. Tout ce que vous demandez existe.

[Jester]

Vous critiquez vos propres lacunes. Tout ce que vous demandez existe.

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.

[*alexandre*]

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.

Ah ben moi dès demain je fais un retour en arrière et développer des statistiques hors de controle des ORM ou tout autre outils mdr ...

[skuatamad]

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.

La 1ere requête en question n'est qu'un JOIN, le WITH utilisé sert juste à simuler la création des tables students et course. Evidemment les CTEs servent, à la base, à factoriser des sous requêtes (et à créer des requêtes hiérarchiques si tu es sur sqlserver ou db2). Mais cette technique de simulation de table est très souvent utilisée sur les forums, car très pratique.

Ah ben moi dès demain je fais un retour en arrière et développer des statistiques hors de controle des ORM ou tout autre outils mdr ...

Je ne comprends pas bien ce que tu veux dire.
Les fonctions analytiques sont justement très utiles pour faire du reporting statistique.

Je ne connais pas bien les langages oo et pas du tout les orm, je peux donc dire des bêtises. Mais d'après ce que j'ai compris sur les orm, si tu n'arrives pas à générer la requête dont tu as besoin, tu peux passer outre et la coder à la main, me trompes je ?

Par contre si tu sous entends qu'en utilisant un langage client et un orm, sans fonctions analytiques, tu peux répondre à la question en moins de 12 lignes de codes, permets moi d'avoir quelques doutes.

Puisque l'on parle de verbosité des langages c'est bien sur le nombre de lignes de codes que l'on va comparer les solutions ... évidemment côté perfs j'ai aussi ma petite idée.

Pour revenir à la problématique de base, je suis assez d'accord avec Waldar.

Ils ne sont pas adaptés à Google ? Pas de soucis, Google invente sa solution qui convient, sur un secteur très particulier. Est-ce que Google a eu raison ? Oui.

J'ajouterais que si google souhaite réinventé la roue comme on peut le lire dans ce thread (ce qui n'est peut être pas tout à fait le cas car la roue ne semble pas tourner si bien pour leur problématique) grand bien leur fasse, au moins ils ont les moyens de leurs ambitions.

Un peu comme les ERP qui ne modélisent pas leurs bases, au moins ils ont la puissance en terme personnel et financier pour arriver à leur fin, ce qui est rarement notre cas, nous incitant à suivre les bonnes pratiques des outils que l'on utilise.

[gregory.broissard]

Personnellement, je suis complétement d'accord avec SQLPro.

Je poursuis mon point de vue.

On vient finalement s'attaquer à ce qui est le plus efficace dans une application, la base de données et l'accès à ses données.

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

Apres qu'ils veuillent proposer des alternatives aux standards en place, pourquoi pas, mais arriver avec leur truc et dire on va remplacer SQL, c'est de la démagogie et de l'utopie collective!

Voilà ma participation au débat, prochaine intervention dès que toutes les bases hiérarchiques IMS/DL1 auront été migrées vers du relationnel. et apres on verra pour une migration vers leur truc... D'ici là, j'en aurai des cheveux blancs!!!

[pseudocode]

Apres qu'ils veuillent proposer des alternatives aux standards en place, pourquoi pas, mais arriver avec leur truc et dire on va remplacer SQL, c'est de la démagogie et de l'utopie collective!

Hum... Pour moi, l' "utopie collective" c'est de croire qu'il est possible (*) de monter, maintenir et gérer une seule grosse base de données répartie sur 500.000 serveurs Oracle (ou SQLServer, MySQL, ...). Parce que c'est que fait Google en ce moment avec son truc démagogique.

(*) et je ne parle même parler de la facilité