voici les champs de ma table announce : ann_id, titre, rank( = toujours 0 )
voici les champs importants de ma table answer:
ans_id, titre, rank, ans_ann_id, ans_ans_id
Je veux faire une sortir de forum en Php-mysql en utilisant les deux
tables ci dessous.
Pour les enregistrements, tout se passe à merveille, mais c'est plus
compliqué pour l'affichage.
Pour ce dernier, je veux afficher les réponses comme pour un forum, cad
des réponses associées à des questions, et des réponses associées à des
réponses de questions.
exemple de table :
*annouce:
ann_id | titre | rank
1 | annonce1 | 0
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
christophe.meresse
voici les champs de ma table announce : ann_id, titre, rank( = toujours 0 )
voici les champs importants de ma table answer: ans_id, titre, rank, ans_ann_id, ans_ans_id
Si c'était moi je ne ferais qu'une seule table (message pour l'exemple) pour les annonces et les reponses avec les champs:
mes_id, titre, rank, mess_mess_id
Comme cela plus besoin de traiter 2 cas different suivant que c'est une reponse à une reponse ou une reponse à une annonce. Et si tu veux obtenir uniquement les annonces tu peux toujours le faire avec un "WHERE mess_mess_id=0".
Je voudrais afficher cela de la manière suivante : [snip]
Pour ca il faut effectivement utiliser une fonction recursive. Cherche un peu sur google groups "recursive affichage php" ca a déjà été expliqué des tas de fois sur ce newsgroup ou sur d'autre.
Christophe
voici les champs de ma table announce : ann_id, titre, rank( = toujours 0 )
voici les champs importants de ma table answer:
ans_id, titre, rank, ans_ann_id, ans_ans_id
Si c'était moi je ne ferais qu'une seule table (message pour
l'exemple) pour les annonces et les reponses
avec les champs:
mes_id, titre, rank, mess_mess_id
Comme cela plus besoin de traiter 2 cas different suivant que c'est une
reponse à une reponse ou une reponse à une annonce.
Et si tu veux obtenir uniquement les annonces tu peux toujours le faire
avec un "WHERE mess_mess_id=0".
Je voudrais afficher cela de la manière suivante :
[snip]
Pour ca il faut effectivement utiliser une fonction recursive. Cherche
un peu sur google groups "recursive affichage php" ca a déjà été
expliqué des tas de fois sur ce newsgroup ou sur d'autre.
voici les champs de ma table announce : ann_id, titre, rank( = toujours 0 )
voici les champs importants de ma table answer: ans_id, titre, rank, ans_ann_id, ans_ans_id
Si c'était moi je ne ferais qu'une seule table (message pour l'exemple) pour les annonces et les reponses avec les champs:
mes_id, titre, rank, mess_mess_id
Comme cela plus besoin de traiter 2 cas different suivant que c'est une reponse à une reponse ou une reponse à une annonce. Et si tu veux obtenir uniquement les annonces tu peux toujours le faire avec un "WHERE mess_mess_id=0".
Je voudrais afficher cela de la manière suivante : [snip]
Pour ca il faut effectivement utiliser une fonction recursive. Cherche un peu sur google groups "recursive affichage php" ca a déjà été expliqué des tas de fois sur ce newsgroup ou sur d'autre.
Christophe
loufoque
Sylvain a dit le 15/09/2005 à 13:03:
voici les champs de ma table announce : ann_id, titre, rank( = toujours 0 )
voici les champs importants de ma table answer: ans_id, titre, rank, ans_ann_id, ans_ans_id
Je veux faire une sortir de forum en Php-mysql en utilisant les deux tables ci dessous.
[...]
SQL et recursivité ne font pas bon ménage, trop de requêtes successives pour l'affichage alors que ce sera la tâche la plus courante de ton application. Tu ferais mieux d'utiliser une technique alternative pour représenter ton arbre, comme les Nested Sets.
Sylvain a dit le 15/09/2005 à 13:03:
voici les champs de ma table announce : ann_id, titre, rank( = toujours 0 )
voici les champs importants de ma table answer:
ans_id, titre, rank, ans_ann_id, ans_ans_id
Je veux faire une sortir de forum en Php-mysql en utilisant les deux
tables ci dessous.
[...]
SQL et recursivité ne font pas bon ménage, trop de requêtes successives
pour l'affichage alors que ce sera la tâche la plus courante de ton
application.
Tu ferais mieux d'utiliser une technique alternative pour représenter
ton arbre, comme les Nested Sets.
voici les champs de ma table announce : ann_id, titre, rank( = toujours 0 )
voici les champs importants de ma table answer: ans_id, titre, rank, ans_ann_id, ans_ans_id
Je veux faire une sortir de forum en Php-mysql en utilisant les deux tables ci dessous.
[...]
SQL et recursivité ne font pas bon ménage, trop de requêtes successives pour l'affichage alors que ce sera la tâche la plus courante de ton application. Tu ferais mieux d'utiliser une technique alternative pour représenter ton arbre, comme les Nested Sets.
Marc
Pour ca il faut effectivement utiliser une fonction recursive. Cherche un peu sur google groups "recursive affichage php" ca a déjà été expliqué des tas de fois sur ce newsgroup ou sur d'autre.
en fait il s'agit de placer un arbre (tree) dans une base de données qui elle est plate. Donc plutot s'orienter avec Tree et database, non ?
Pour ca il faut effectivement utiliser une fonction recursive. Cherche
un peu sur google groups "recursive affichage php" ca a déjà été
expliqué des tas de fois sur ce newsgroup ou sur d'autre.
en fait il s'agit de placer un arbre (tree) dans une base
de données qui elle est plate. Donc plutot s'orienter avec
Tree et database, non ?
Pour ca il faut effectivement utiliser une fonction recursive. Cherche un peu sur google groups "recursive affichage php" ca a déjà été expliqué des tas de fois sur ce newsgroup ou sur d'autre.
en fait il s'agit de placer un arbre (tree) dans une base de données qui elle est plate. Donc plutot s'orienter avec Tree et database, non ?
christophe.meresse
SQL et recursivité ne font pas bon ménage, trop de requêtes successives pour l'affichage alors que ce sera la tâche la plus courante de ton application.
Oui effectivement mais si on estime qu'il n'y aura pas trop de donnees, on peut faire la requete sql pour tout recuperer dans une table et faire la recursivité en memoire. A mon avis c'est jouable comme cela avec même plusieurs milliers de records. Et ensuite si on veut faire mieux, il faut gerer un binary tree pour pouvoir obtenir facilement avec un select une petite partie de l'arbre (Juste quelque question avec leur reponses dans ce cas precis) Pour ca, il y a un article de Gijs Van Tulder que j'avais trouvé très bien fait: <http://www.sitepoint.com/article/hierarchical-data-database>
A+ Christophe
SQL et recursivité ne font pas bon ménage, trop de requêtes successives
pour l'affichage alors que ce sera la tâche la plus courante de ton
application.
Oui effectivement mais si on estime qu'il n'y aura pas trop de donnees,
on peut faire la requete sql pour tout recuperer dans une table et
faire la recursivité en memoire. A mon avis c'est jouable comme cela
avec même plusieurs milliers de records.
Et ensuite si on veut faire mieux, il faut gerer un binary tree pour
pouvoir obtenir facilement avec un select une petite partie de l'arbre
(Juste quelque question avec leur reponses dans ce cas precis)
Pour ca, il y a un article de Gijs Van Tulder que j'avais trouvé très
bien fait:
<http://www.sitepoint.com/article/hierarchical-data-database>
SQL et recursivité ne font pas bon ménage, trop de requêtes successives pour l'affichage alors que ce sera la tâche la plus courante de ton application.
Oui effectivement mais si on estime qu'il n'y aura pas trop de donnees, on peut faire la requete sql pour tout recuperer dans une table et faire la recursivité en memoire. A mon avis c'est jouable comme cela avec même plusieurs milliers de records. Et ensuite si on veut faire mieux, il faut gerer un binary tree pour pouvoir obtenir facilement avec un select une petite partie de l'arbre (Juste quelque question avec leur reponses dans ce cas precis) Pour ca, il y a un article de Gijs Van Tulder que j'avais trouvé très bien fait: <http://www.sitepoint.com/article/hierarchical-data-database>
A+ Christophe
loufoque
a dit le 15/09/2005 23:42:
Pour ca, il y a un article de Gijs Van Tulder que j'avais trouvé très bien fait: <http://www.sitepoint.com/article/hierarchical-data-database>
Il s'agit effectivement des Nested Sets. Son article n'est pas terrible du tout je trouve.
Il ne propose que 4 actions différentes, et l'une est quasi-inutile et deux erronnées alors que pour pouvoir les utiliser on aurait besoin de savoir faire bien plus d'actions.
Par exemple dans sa fonction display_tree il fait deux requêtes, stocke des données en mémoire, fait des tests etc. tout ça pour obtenir le niveau alors qu'il pourrait demander à son SGBD de lui calculer le niveau d'imbrication en même temps qu'il lui fournit les données en une requête.
Ensuite, pour son code d'insertion, il oublie de préciser qu'il est indispensable de faire une transaction, sans quoi, tout peut être bousillé.
christophe.meresse@gadz.org a dit le 15/09/2005 23:42:
Pour ca, il y a un article de Gijs Van Tulder que j'avais trouvé très
bien fait:
<http://www.sitepoint.com/article/hierarchical-data-database>
Il s'agit effectivement des Nested Sets.
Son article n'est pas terrible du tout je trouve.
Il ne propose que 4 actions différentes, et l'une est quasi-inutile et
deux erronnées alors que pour pouvoir les utiliser on aurait besoin de
savoir faire bien plus d'actions.
Par exemple dans sa fonction display_tree il fait deux requêtes, stocke
des données en mémoire, fait des tests etc. tout ça pour obtenir le
niveau alors qu'il pourrait demander à son SGBD de lui calculer le
niveau d'imbrication en même temps qu'il lui fournit les données en une
requête.
Ensuite, pour son code d'insertion, il oublie de préciser qu'il est
indispensable de faire une transaction, sans quoi, tout peut être bousillé.
Pour ca, il y a un article de Gijs Van Tulder que j'avais trouvé très bien fait: <http://www.sitepoint.com/article/hierarchical-data-database>
Il s'agit effectivement des Nested Sets. Son article n'est pas terrible du tout je trouve.
Il ne propose que 4 actions différentes, et l'une est quasi-inutile et deux erronnées alors que pour pouvoir les utiliser on aurait besoin de savoir faire bien plus d'actions.
Par exemple dans sa fonction display_tree il fait deux requêtes, stocke des données en mémoire, fait des tests etc. tout ça pour obtenir le niveau alors qu'il pourrait demander à son SGBD de lui calculer le niveau d'imbrication en même temps qu'il lui fournit les données en une requête.
Ensuite, pour son code d'insertion, il oublie de préciser qu'il est indispensable de faire une transaction, sans quoi, tout peut être bousillé.
christophe.meresse
a dit le 15/09/2005 23:42:
Pour ca, il y a un article de Gijs Van Tulder que j'avais trouvé très bien fait: <http://www.sitepoint.com/article/hierarchical-data-database>
Il s'agit effectivement des Nested Sets. Son article n'est pas terrible du tout je trouve. Il ne propose que 4 actions différentes, et l'une est quasi-inutile et deux erronnées alors que pour pouvoir les utiliser on aurait besoin de savoir faire bien plus d'actions.
Par exemple dans sa fonction display_tree il fait deux requêtes, stocke des données en mémoire, fait des tests etc. tout ça pour obtenir le niveau alors qu'il pourrait demander à son SGBD de lui calculer le niveau d'imbrication en même temps qu'il lui fournit les données en une requête.
Ah, bon, il est vrai que je n'ai pas passé de temps à comparer de nombreux articles et celui là m'avait malgre tout bien aidé mais si tu connais mieux je suis preneur.
Ensuite, pour son code d'insertion, il oublie de préciser qu'il est indispensable de faire une transaction, sans quoi, tout peut être bousillé.
Oui c'est vrai, malheureusement les transactions ne sont pas supportées par toute les DB et on est bien obligé de faire avec...
A+ Christophe
christophe.meresse@gadz.org a dit le 15/09/2005 23:42:
Pour ca, il y a un article de Gijs Van Tulder que j'avais trouvé très
bien fait:
<http://www.sitepoint.com/article/hierarchical-data-database>
Il s'agit effectivement des Nested Sets.
Son article n'est pas terrible du tout je trouve.
Il ne propose que 4 actions différentes, et l'une est quasi-inutile et
deux erronnées alors que pour pouvoir les utiliser on aurait besoin de
savoir faire bien plus d'actions.
Par exemple dans sa fonction display_tree il fait deux requêtes, stocke
des données en mémoire, fait des tests etc. tout ça pour obtenir le
niveau alors qu'il pourrait demander à son SGBD de lui calculer le
niveau d'imbrication en même temps qu'il lui fournit les données en une
requête.
Ah, bon, il est vrai que je n'ai pas passé de temps à comparer de
nombreux articles et celui là m'avait malgre tout bien aidé mais si
tu connais mieux je suis preneur.
Ensuite, pour son code d'insertion, il oublie de préciser qu'il est
indispensable de faire une transaction, sans quoi, tout peut être bousillé.
Oui c'est vrai, malheureusement les transactions ne sont pas
supportées par toute les DB et on est bien obligé de faire avec...
Pour ca, il y a un article de Gijs Van Tulder que j'avais trouvé très bien fait: <http://www.sitepoint.com/article/hierarchical-data-database>
Il s'agit effectivement des Nested Sets. Son article n'est pas terrible du tout je trouve. Il ne propose que 4 actions différentes, et l'une est quasi-inutile et deux erronnées alors que pour pouvoir les utiliser on aurait besoin de savoir faire bien plus d'actions.
Par exemple dans sa fonction display_tree il fait deux requêtes, stocke des données en mémoire, fait des tests etc. tout ça pour obtenir le niveau alors qu'il pourrait demander à son SGBD de lui calculer le niveau d'imbrication en même temps qu'il lui fournit les données en une requête.
Ah, bon, il est vrai que je n'ai pas passé de temps à comparer de nombreux articles et celui là m'avait malgre tout bien aidé mais si tu connais mieux je suis preneur.
Ensuite, pour son code d'insertion, il oublie de préciser qu'il est indispensable de faire une transaction, sans quoi, tout peut être bousillé.
Oui c'est vrai, malheureusement les transactions ne sont pas supportées par toute les DB et on est bien obligé de faire avec...
A+ Christophe
loufoque
a dit le 16/09/2005 à 12:32:
Ah, bon, il est vrai que je n'ai pas passé de temps à comparer de nombreux articles et celui là m'avait malgre tout bien aidé mais si tu connais mieux je suis preneur.
Explication de l'auteur. http://searchoracle.techtarget.com/tip/1,289483,sid13_gci537290,00.html
Oui c'est vrai, malheureusement les transactions ne sont pas supportées par toute les DB et on est bien obligé de faire avec...
MyISAM de MySQL ne les supporte pas, c'est vrai, mais bon au pire on peut verrouiller la table en écriture. Et puis y'a InnoDB.
christophe.meresse@gadz.org a dit le 16/09/2005 à 12:32:
Ah, bon, il est vrai que je n'ai pas passé de temps à comparer de
nombreux articles et celui là m'avait malgre tout bien aidé mais si
tu connais mieux je suis preneur.
Explication de l'auteur.
http://searchoracle.techtarget.com/tip/1,289483,sid13_gci537290,00.html
Oui c'est vrai, malheureusement les transactions ne sont pas
supportées par toute les DB et on est bien obligé de faire avec...
MyISAM de MySQL ne les supporte pas, c'est vrai, mais bon au pire on
peut verrouiller la table en écriture. Et puis y'a InnoDB.
Ah, bon, il est vrai que je n'ai pas passé de temps à comparer de nombreux articles et celui là m'avait malgre tout bien aidé mais si tu connais mieux je suis preneur.
Explication de l'auteur. http://searchoracle.techtarget.com/tip/1,289483,sid13_gci537290,00.html
Oui c'est vrai, malheureusement les transactions ne sont pas supportées par toute les DB et on est bien obligé de faire avec...
MyISAM de MySQL ne les supporte pas, c'est vrai, mais bon au pire on peut verrouiller la table en écriture. Et puis y'a InnoDB.
