Il a ptêt pas entièrement tort

Parfaitement

et vive MySQL3 sans clés étrangères ni rien du tout

Il n'y a pas de raison de ne pas avoir un autre langage pour les requêtes, vu qu'on a bien plein de langages de programmation...

Heu... oui, mais encore ? ils ont quelque chose à proposer ou c'est juste un rêve précurseur ?

antoinette : il suffirais que je lise

les annonces lachées dans le vent comme ça me paraissent toujours très abstraites... Je n'arrive pas à concevoir comment une base de données pourrait être conçue autrement qu'en SQL

En XMLOO ?

J'ai lu le rapport

Ils remettent en cause le langage SQL et c'est une très bonne chose: le SQL a été imaginé à une époque où on croyait que les managers allaient vouloir écrire leurs propres requêtes (comme le Query By Example), donc on a fait un truc proche de l'anglais, mais dont la sémantique devait être aussi riche que l'algèbre relationnelle. Le résultat est que ce n'est pas utilisable par un manager moyen, et que c'est une plaie pour ceux qui doivent l'utiliser. Ce que dit aussi le rapport, c'est qu'on a en général un nombre limité de requêtes et transactions sur une DB donnée, et c'est totalement vrai.

Pour ceux qui se demandent par quoi on pourrait remplacer le SQL, je les ivite à se renseigner sur la théorie à la base des bases de données relationnelles.
Quelques opérateurs algébriques suffisent et le tour est joué. Un compilateur optimisera la DB pour la poignée de requêtes que l'on a à faire dessus.

Ce que le rapport remet aussi en question, c'est la validité même du modèle relationnel, et là je suis pas d'accord. Leur argumentation est d'ailleurs un peu foireuse:
- le modèle a été conçu pour le disque quand la mémoire était rare: vrai, mais un OS moderne unifie le stockage disque et mémoire (caching, mmap()...) Le modèle est d'ailleurs totalement valide indépendamment de l'implémentation mémoire ou disque.
- le modèle entity-relationship est plus approprié à la plupart des cas: peut-être, c'est d'ailleurs ce qu'on voit se développer comme modèles d'"object persistance", qui, s'ils sont implémentés au-dessus d'une DB (par un "object-relational mapper") profitent de sa robustesse, réplication, backup, ... sans devoir réinventer la roue. Cela non plus ne remet donc pas en cause le modèle.
- les autres exemples donnés sont des contre-exemples gratuits: "Text processing obviously has never used a relational model." C'est vrai, et ma machine à café non plus

Bref, je suis d'accord pour tuer le SQL, mais le modèle relationnel a trop fait ses preuves pour être abandonné.
Les tables et les formes normales font partie de la culture des concepteurs de DB, et le modèle relationnel en soi ne handicape pas les performances d'une implémentation correcte.

Puis, je ne sais pas trop si on peut se fier à Ingres pour ce qui est de la modernité: même de son vivant, il était plutôt considéré comme un classique, alors faut pas demander maintenant...
Et en matière de programmation, je rigole: un mec qui peignait la Grande Odalisque avec trois vertèbres de trop, il a juste le droit de se la boucler, hein.

H2G2>

philfr> Merci pour ton analyse et tes explications sur ta vision de la chose.

Pour ma part je suis aussi très d'accord sur le fait que les transactions ne sont plus du tout en accord avec le développement web si bien qu'en définitive on programme une bonne partie dans le code (via des sessions pour plusieurs pages) avant de tout envoyer à la DB, et impossible clairement de locker une table pendant tout ce temps (et même au niveau d'un row, c'est parfois fort gênant).

De voir disparaître le SQL ne me chagrinerait pas vraiment non plus. Que l'on remplace le tout par une API standardisée serait peut être une solution

Pour le stockage, si ils peuvent apporter une solution pour que l'on puisse facilement sérialiser et récupérer les données d'un objet dans tous les languages de haut niveau (via des interfaces?) je suis prêt à oublier le relationnel, mais le concept ne s'en éloignera probablement pas beaucoup.