Quote:
Tiens donc... et pourquoi ne suis-je pas étonné ?
Rien de personnel là dedans, sinon j'aurais trouvé le moyen de dire d'emblée que l'avis de jrebillat était mauvais :lol: ;)
Surtout que c'était facile. En fait dbobby dans sa présentation du problème induit quelque chose qui est assez contre nature, à savoir sauvegarder dans une *même* table, des données en fonction d'autres données de la dite table. C'est contre nature en SQL et c'est donc normal que SQL ne soit pas performant sur ce coup puisqu'il est utilisé à contre emploi.
C'est vicié à la base (si je peux dire :D).
Quote:
pour moi une base de données, c'est fait pour être interrogé par du code... Je n'envisageais pas du tout du "tout-SQL"
C'est que là ce n'est pas si évident. Bon bien sûr, le gag Access on oublie.
Mais une base de données c'est fait pour être interrogé non par du code quelconque mais par du code SQL. Ca fait une grosse différence. C'est pour cela que dans ces situations, on utilise des procédures stockées récursives. Parce que une seule requête traite tout le problème.
Sinon, la récursivité étant inévitable puisqu'on a des données arborescentes, qui va l'effectuer ? Un langage X en faisant des appels récursifs avec dans chaque appel une requête SQL simple ?
Le problème est que si l'arborescence est un peu grande, ce qui est probable dans notre cas (les éventuelles familles nombreuses) le nombre de requêtes à formuler va exploser exponentiellement.
Dans le cas de clients lourds (ou riches comme on dit maintenant), le traffic réseau va être surchargé et le SGDBR aussi car il devra compiler les requêtes au passage à chaque appel. Dans le cas d'un client léger (navigateur) ce sera alors (par exemple) du code Php qui va mouliner et augmenter la charge du serveur avec éventuellement un débordement de pile ou un épuisement mémoire à la clef. (et le SGDBR reste tout autant sollicité d'ailleurs). Ca va être difficile de tenir la charge (oui je sais encore mon buzz sur la charge, mais quand on fait de l'informatique c'est une chose à laquelle il est bon penser ;) ) Tandis qu'avec une procédure stockée, on peut raisonnablement croire que les traitements seront optimisés et on s'affanchit de la compilation de la requête.
Bon maintenant sans doute il serait judicieux de repenser tout le problème, et d'utiliser des outils adaptés à un problème qui n'est pas du tout anodin, des outils capables de travailler sur les graphes de façon naturelle. Evidemment je pense à des outils "à esprit tordu". Alors là je me contente seulement d'évoquer ;)
Rien de personnel là dedans, sinon j'aurais trouvé le moyen de dire d'emblée que l'avis de jrebillat était mauvais :lol: ;)
Surtout que c'était facile. En fait dbobby dans sa présentation du problème induit quelque chose qui est assez contre nature, à savoir sauvegarder dans une *même* table, des données en fonction d'autres données de la dite table. C'est contre nature en SQL et c'est donc normal que SQL ne soit pas performant sur ce coup puisqu'il est utilisé à contre emploi.
C'est vicié à la base (si je peux dire :D).
C'est que là ce n'est pas si évident. Bon bien sûr, le gag Access on oublie.
Mais une base de données c'est fait pour être interrogé non par du code quelconque mais par du code SQL. Ca fait une grosse différence. C'est pour cela que dans ces situations, on utilise des procédures stockées récursives. Parce que une seule requête traite tout le problème.
Sinon, la récursivité étant inévitable puisqu'on a des données arborescentes, qui va l'effectuer ? Un langage X en faisant des appels récursifs avec dans chaque appel une requête SQL simple ?
Le problème est que si l'arborescence est un peu grande, ce qui est probable dans notre cas (les éventuelles familles nombreuses) le nombre de requêtes à formuler va exploser exponentiellement.
Dans le cas de clients lourds (ou riches comme on dit maintenant), le traffic réseau va être surchargé et le SGDBR aussi car il devra compiler les requêtes au passage à chaque appel. Dans le cas d'un client léger (navigateur) ce sera alors (par exemple) du code Php qui va mouliner et augmenter la charge du serveur avec éventuellement un débordement de pile ou un épuisement mémoire à la clef. (et le SGDBR reste tout autant sollicité d'ailleurs). Ca va être difficile de tenir la charge (oui je sais encore mon buzz sur la charge, mais quand on fait de l'informatique c'est une chose à laquelle il est bon penser ;) ) Tandis qu'avec une procédure stockée, on peut raisonnablement croire que les traitements seront optimisés et on s'affanchit de la compilation de la requête.
Bon maintenant sans doute il serait judicieux de repenser tout le problème, et d'utiliser des outils adaptés à un problème qui n'est pas du tout anodin, des outils capables de travailler sur les graphes de façon naturelle. Evidemment je pense à des outils "à esprit tordu". Alors là je me contente seulement d'évoquer ;)