Discussion :

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

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

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

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

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

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