Visiblement j'avais mal formulé mon post la derniere fois et donc il a
ete refusé par les ops (je ne jette pas la pierre, c'est ma faute :-p)
Donc ce que je voulais c'etait pouvoir afficher le resultat d'une
requete sql qui donnait ceci:
+----------------+
| Parent | Child |
+----------------+
| A | AA |
| A | AB |
| A | AC |
| AA | AAA |
| AA | AAB |
| AB | ABA |
| AAB | AABA |
| B | |
| C | CA |
| C | CB |
+----------------+
J'aimerais pouvoir afficher, grace à PHP (sisi, j'vous jure), la hierarchie:
A
-- AA
-- AAA
-- AAB
-- AABA
-- AB
-- ABA
B
C
-- CA
-- CB
Je ne sais pas comment coder ceci ... dois-je passer par un tableau
alternatif ou grace à mon resultset, je sais le faire directement? ou
alors, dois-je passer par une fonction recursive? (j'aime pas le recursif)
D'où la technique que j'ai fournie : pratique, puissante, performante et dont apparemment tout le monde se fout.
Non: j'ai trouvé cette solution très intelligente, les problèmes que j'ai trouvé: * Complexité dans la gestion des items dans la bdd: index à gerer, moyen de recherche, etc... * problème d'atomicité ou de sémaphore pour ne pas mettre la base en vrac. Solution alternative pour gerer cette atomicité: les triggers, mais tout les SGBD ne les ont pas, donc pas universel.
Donc: c'est un peu plus le bordel à gerer, mais cela a l'avantage d'être certainement bcp plus rapide sur des arbre un peu touffu. Le recursif est souvent très elegant à utiliser, programmer, permet de simplifier l'approche, mais il ralenti et demande plus de ressource lorsque les données sont importantes. Exemple simple: Fibonnacci.
Il manque plus qu'a quelqu'un de publier une belle classe qui encapsule tout se beau bazar de gestion de manière à presenter qq chose de très simple à utiliser. C'est ce que j'ai fait avec ma classe qui gere l'arbre de manière recursive.
D'où la technique que j'ai fournie : pratique, puissante, performante et
dont apparemment tout le monde se fout.
Non: j'ai trouvé cette solution très intelligente, les problèmes que
j'ai trouvé:
* Complexité dans la gestion des items dans la bdd: index à gerer, moyen
de recherche, etc...
* problème d'atomicité ou de sémaphore pour ne pas mettre la base en
vrac. Solution alternative pour gerer cette atomicité: les triggers,
mais tout les SGBD ne les ont pas, donc pas universel.
Donc: c'est un peu plus le bordel à gerer, mais cela a l'avantage d'être
certainement bcp plus rapide sur des arbre un peu touffu. Le recursif
est souvent très elegant à utiliser, programmer, permet de simplifier
l'approche, mais il ralenti et demande plus de ressource lorsque les
données sont importantes. Exemple simple: Fibonnacci.
Il manque plus qu'a quelqu'un de publier une belle classe qui encapsule
tout se beau bazar de gestion de manière à presenter qq chose de très
simple à utiliser. C'est ce que j'ai fait avec ma classe qui gere
l'arbre de manière recursive.
D'où la technique que j'ai fournie : pratique, puissante, performante et dont apparemment tout le monde se fout.
Non: j'ai trouvé cette solution très intelligente, les problèmes que j'ai trouvé: * Complexité dans la gestion des items dans la bdd: index à gerer, moyen de recherche, etc... * problème d'atomicité ou de sémaphore pour ne pas mettre la base en vrac. Solution alternative pour gerer cette atomicité: les triggers, mais tout les SGBD ne les ont pas, donc pas universel.
Donc: c'est un peu plus le bordel à gerer, mais cela a l'avantage d'être certainement bcp plus rapide sur des arbre un peu touffu. Le recursif est souvent très elegant à utiliser, programmer, permet de simplifier l'approche, mais il ralenti et demande plus de ressource lorsque les données sont importantes. Exemple simple: Fibonnacci.
Il manque plus qu'a quelqu'un de publier une belle classe qui encapsule tout se beau bazar de gestion de manière à presenter qq chose de très simple à utiliser. C'est ce que j'ai fait avec ma classe qui gere l'arbre de manière recursive.
loufoque
Julien PACHET a dit le 19/02/2005 à 22:56:
* problème d'atomicité ou de sémaphore pour ne pas mettre la base en vrac. Solution alternative pour gerer cette atomicité: les triggers, mais tout les SGBD ne les ont pas, donc pas universel.
Tout SGBD digne de ce nom permet les transactions.
Julien PACHET a dit le 19/02/2005 à 22:56:
* problème d'atomicité ou de sémaphore pour ne pas mettre la base en
vrac. Solution alternative pour gerer cette atomicité: les triggers,
mais tout les SGBD ne les ont pas, donc pas universel.
Tout SGBD digne de ce nom permet les transactions.
* problème d'atomicité ou de sémaphore pour ne pas mettre la base en vrac. Solution alternative pour gerer cette atomicité: les triggers, mais tout les SGBD ne les ont pas, donc pas universel.
Tout SGBD digne de ce nom permet les transactions.
John GALLET
Cependant, attention aux raccourcis trompeurs. Et aux connaissances basiques. Le arbres binaires orientés
horizontalement/verticalement, c'est du cours basique de gestion mémoire, mais bon, apparement il y en a qui découvrent.
Cette technique et puissante, performante ... en lecture En effet, l'insertion de données est une catastrophe en terme de performances et extremenent risquée lorsqu'on ne dispose pas des transactions.
Ces algos sont adaptés à de la gestion mémoire mono process/threadsafe en mutex. Il n'y a que trois pointeurs à bouger et youpi. Je ne vois pas l'intérêt pratique (je parle une fois de plus de la vraie vie, pas d'esthétisme) de les mettre en oeuvre sur des structures de SGBDR.
a++; JG
Cependant, attention aux raccourcis trompeurs.
Et aux connaissances basiques. Le arbres binaires orientés
horizontalement/verticalement, c'est du cours basique de gestion mémoire,
mais bon, apparement il y en a qui découvrent.
Cette technique et puissante, performante ... en lecture
En effet, l'insertion de données est une catastrophe en terme de
performances et extremenent risquée lorsqu'on ne dispose pas des
transactions.
Ces algos sont adaptés à de la gestion mémoire mono process/threadsafe en
mutex. Il n'y a que trois pointeurs à bouger et youpi. Je ne vois pas
l'intérêt pratique (je parle une fois de plus de la vraie vie, pas
d'esthétisme) de les mettre en oeuvre sur des structures de SGBDR.
Cependant, attention aux raccourcis trompeurs. Et aux connaissances basiques. Le arbres binaires orientés
horizontalement/verticalement, c'est du cours basique de gestion mémoire, mais bon, apparement il y en a qui découvrent.
Cette technique et puissante, performante ... en lecture En effet, l'insertion de données est une catastrophe en terme de performances et extremenent risquée lorsqu'on ne dispose pas des transactions.
Ces algos sont adaptés à de la gestion mémoire mono process/threadsafe en mutex. Il n'y a que trois pointeurs à bouger et youpi. Je ne vois pas l'intérêt pratique (je parle une fois de plus de la vraie vie, pas d'esthétisme) de les mettre en oeuvre sur des structures de SGBDR.
a++; JG
John GALLET
* problème d'atomicité ou de sémaphore pour ne pas mettre la base en vrac. Solution alternative pour gerer cette atomicité: les triggers, mais tout les SGBD ne les ont pas, donc pas universel.
Tout SGBD digne de ce nom permet les transactions.
Je suis tout à fait d'accord avec cette affirmation en tant que développeur soucieux d'avoir les outils minimalistes pour bosser dans de bonnes conditions.
J'ajouterais même qu'il faut que le SGBD en question gère du row level lock, sinon c'est le bordel : en table lock, ça sérialise à mort, en page lock ce sont les deadlocks assurés au quotidien.
En revanche, il est grand temps que tu apprennes/admettes que DANS LA VRAIE VIE on ne dispose pas nécessairement de ce qu'il faut pour bosser en conditions optimales, et de toutes façons, moins on fait de transactions (en privilégiant les requêtes atomiques) mieux ça vaut.
Arrête la branlette intellectuelle et revient dans la vraie vie de l'entreprise. Je sais pas où tu bosses, mais il est clair que je risque pas de t'embaucher avec aussi peu de vision réaliste. Les programmes d'esthètes, ça reste des ... programmes d'esthètes.
a++; JG
* problème d'atomicité ou de sémaphore pour ne pas mettre la base en
vrac. Solution alternative pour gerer cette atomicité: les triggers,
mais tout les SGBD ne les ont pas, donc pas universel.
Tout SGBD digne de ce nom permet les transactions.
Je suis tout à fait d'accord avec cette affirmation en tant que
développeur soucieux d'avoir les outils minimalistes pour bosser dans de
bonnes conditions.
J'ajouterais même qu'il faut que le SGBD en question gère du row level
lock, sinon c'est le bordel : en table lock, ça sérialise à mort, en page
lock ce sont les deadlocks assurés au quotidien.
En revanche, il est grand temps que tu apprennes/admettes que DANS LA
VRAIE VIE on ne dispose pas nécessairement de ce qu'il faut pour bosser en
conditions optimales, et de toutes façons, moins on fait de transactions
(en privilégiant les requêtes atomiques) mieux ça vaut.
Arrête la branlette intellectuelle et revient dans la vraie vie de
l'entreprise. Je sais pas où tu bosses, mais il est clair que je risque
pas de t'embaucher avec aussi peu de vision réaliste. Les programmes
d'esthètes, ça reste des ... programmes d'esthètes.
* problème d'atomicité ou de sémaphore pour ne pas mettre la base en vrac. Solution alternative pour gerer cette atomicité: les triggers, mais tout les SGBD ne les ont pas, donc pas universel.
Tout SGBD digne de ce nom permet les transactions.
Je suis tout à fait d'accord avec cette affirmation en tant que développeur soucieux d'avoir les outils minimalistes pour bosser dans de bonnes conditions.
J'ajouterais même qu'il faut que le SGBD en question gère du row level lock, sinon c'est le bordel : en table lock, ça sérialise à mort, en page lock ce sont les deadlocks assurés au quotidien.
En revanche, il est grand temps que tu apprennes/admettes que DANS LA VRAIE VIE on ne dispose pas nécessairement de ce qu'il faut pour bosser en conditions optimales, et de toutes façons, moins on fait de transactions (en privilégiant les requêtes atomiques) mieux ça vaut.
Arrête la branlette intellectuelle et revient dans la vraie vie de l'entreprise. Je sais pas où tu bosses, mais il est clair que je risque pas de t'embaucher avec aussi peu de vision réaliste. Les programmes d'esthètes, ça reste des ... programmes d'esthètes.
a++; JG
Jean-Marc Molina
pounch a écrit/wrote :
Donc ce que je voulais c'etait pouvoir afficher le resultat d'une requete sql qui donnait ceci: ... J'aimerais pouvoir afficher, grace à PHP (sisi, j'vous jure), la hierarchie:
Question mille et une fois posée sur ce groupe, une simple recherche sur hiérarchie ou arborescence t'apportera toutes les réponses dont tu as besoin. Ce genre de réponse devrait être automatique :).
En espérant que ce conseil te servira pour la prochaine fois. Ça évite quand même aux autres de perdre leur temps... Puis on est tous plus efficace après :).
-- Jean-Marc.
pounch a écrit/wrote :
Donc ce que je voulais c'etait pouvoir afficher le resultat d'une
requete sql qui donnait ceci:
...
J'aimerais pouvoir afficher, grace à PHP (sisi, j'vous jure), la
hierarchie:
Question mille et une fois posée sur ce groupe, une simple recherche sur
hiérarchie ou arborescence t'apportera toutes les réponses dont tu as
besoin. Ce genre de réponse devrait être automatique :).
En espérant que ce conseil te servira pour la prochaine fois. Ça évite quand
même aux autres de perdre leur temps... Puis on est tous plus efficace après
:).
Donc ce que je voulais c'etait pouvoir afficher le resultat d'une requete sql qui donnait ceci: ... J'aimerais pouvoir afficher, grace à PHP (sisi, j'vous jure), la hierarchie:
Question mille et une fois posée sur ce groupe, une simple recherche sur hiérarchie ou arborescence t'apportera toutes les réponses dont tu as besoin. Ce genre de réponse devrait être automatique :).
En espérant que ce conseil te servira pour la prochaine fois. Ça évite quand même aux autres de perdre leur temps... Puis on est tous plus efficace après :).
