Reprise du message précédent :
bin non, c'est le numéro de ligne en interne de 0 à mysql_num_rows()-1, les colonnes ont rien à voir
 
t'as combien de chiens en tout ?

et t'es obligé de tout mettre dans la meme page ?

En fait si j'ai bien compris tu veut obtenir la descendance d'un chien (cad une belle structure hiérarchique) à partir de la liste des chiens (qui ont je suppose chacun 2 attributs "parent" dans la db ?). Et pour l'instant tu récupère tout les chiens et tu résouds l'arbre en php, mais evidemment, c'est lent ?

 
Zut, c'est ce que je cherchais justement.
 

Moi 2.    
Mais dans la base, là il y en a 5000 et ça grossit chaque jour.
 

Quand ce sera trop gros, c'est ce que je serais obligé de faire, dissocier par ordre alphabétique.
Mais je suis obligé de tous les récupérer de toutes façons pour d'autres pages, comme les pedigrees.
 

T'as tout compris.

et t'as pas essayé de faire un arbre SQL ? y'a un tuto bien foutu sur developpez.com
 
hop, comme ici : http://sqlpro.developpez.com/cours/arborescence/

Normalement, si tu fais ca uniquement à coup de requètes SQL, tu n'aura qu'autant de requète SQL que la profondeur de ton arbre ? ( première requète tu récupère l'id des 2 parents du 1er, ensuite 2eme requète tu récupère d'un coup les 4 parents des 2 parents précédents, etc ... ) Sur la page que tu a montré ca ne fait que 3 requètes, c'est pas très classe mais ce sera peut-être plus rapide, t'as déja essayé ?
 
[edit]
 
La méthode à Sherd@r est bcp plus efficace cela dit

ça serait plus rapide avec plus de requêtes légères je pense
 
sinon c'est pas de moi hein
 
EDIT : et au pire, plutôt qu'une requête par niveau, tu peux faire une auto jointure à chaque fois et diviser les requêtes par 2 non ?

Vi jme doute que c'est pas de toi
 
Par contre le problème de leur implémentation c'est la lourdeur des insertions suppressions Quoique j'ai ptêtre une idée pour améliorer ca

Sur cette page, regardes les options et choisis l'affichage sur 7 générations et regarde le nombre de requête que ça ferait.  
 
Sinon, je vais voir pour l'arbre hiérarchique en MySQL.

bin y'a de l'idée, mais vu que j'avais que quelques centaines de feuilles, j'ai bourriné ça dans un tableau

Bha 7 générations -> 7 requètes
 
->SELECT idpapa,idmaman,id WHERE id=42
<- [ 21,23,42 ]
->SELECT idpapa,idmaman,id WHERE id=21 or id=23
<- [ 12,14,21]
[ 7,11,23]
-> SELECT idpapa,idmaman,id WHERE id=12 or id=14 or id=11 or id=7
<- un tableau de 4 lignes
etc...
 
Tu récupère génération par génération, pas chien par chien

J'y comprends rien, j'suis pas assez doué. :s
 
C'est quand même dingue qu'en PHP, il n'y ai rien pour transformer un résultat de requête en tableau indéxé sans passer par une boucle.

à la septième génération, ça fait 128 "or", "id=1 or id=2 or id=4 or id=6" ça mets MySQL à genoux si tu en mets trop, j'avais essayé, c'est très efficace sur un "petit" nombre de "or", mais autrement, ça mettais du temps chez moi.

pour retrouver les parents c'est super simple, suffit de lire les 2 ancetres que tu as enregistré (je me doute que c'est ce que tu fais)
pour aller dans l'autre sens, tu pourrais aussi enregistrer la descendance dans une autre table (qui serait enorme cela dit) avec tous les enfants de chaque chien...
comme ça, ça irait (presque) aussi vite dans les deux sens, et pas besoin de se taper toute la table...

 
 
avec une jointure pour choper la génération suivante/précédente et on divise par deux non ?
 
un truc dans ce genre là
 
SELECT
A.idpapa,
A.idmaman,
B.idpapa as idpapy,
B.idmaman as idmamy
FROM matable AS A
LEFT JOIN matable AS B ON ( B.id = A.idmaman OR  B.id = A.idpapa)
where A.id = id de mon chien
 

Mais vous imaginez pas la requête.
 
Déjà, rien qu'en PHP, j'ai un truc comme ça pour l'affichage du père du père du père de la mère, ... :

Oh mon dieu

C'est bon j'ai édité, je me doutais que j'aurais ce genre de réaction.  

 
Y'a pas un mot clef "IN" en sql déja qui pourait faire un bon remplacement ?

 
 
bin tu dois pas devoir imbriquer plus de tableaux qu'il n'y a de niveaux non ? là y'en a déjà 9..
 
tu devrais faire péter le code, à mon avis y'a vraiment de quoi optimiser..

(oracle roske. Connect by/start with + création de l'arbre en php for the win)

 
Oui, y'a de quoi optimiser, déjà, j'ai fait ligne à ligne alors que j'aurais pu faire une boucle mais au départ, je ne voulais le faire que sur 3 gen (comme un pedigree officiel quoi) et après, ma femme m'en a demandé plus et j'ai bricolé.
Mais à ce niveau là, ça n'irais pas plus vite, c'est surtout au niveau de l'enregistrement du tableau que ça ralentit tout, genre la page se génère en 0,8 s, il en faut 0,7 rien que pour copier le tableau recup de MySQL en array PHP.

Accessoirement, sans partir dans une bataille (habituelle) tableau/css, si tu fait le tout avec quelques listes et des css, tu peut générer l'arbre "verticalement" (génération par génération), ca te fait une boucle globale :
-> faire la requète pour la génération X
-> balancer le code html pour cette génération
-> on reprends on début pour la génération X+1
 
Le tout devrait être nettement plus simple en code que ton truc actuel je pense

kadreg ? c'est toi ?

le mieux c'est encore une bonne table de lookup à 2 dimensions précalculée ! tu exploses la RAM, mais tu exploses les perfs aussi

sans partir dans une bataille (habituelle) tableau/css, en CSS, j'avais des problèmes d'alignement quand les gens affichent toutes les infos, notemment les commentaires qui peuvent être très grand.
Bon et après, je suis conscient que y'a largement à optimiser niveau CSS, mais ce n'était pas ma priorité pour le moment, c'était déjà un boulot énorme pour du "gratos".
J'ai même appris la génération de PDF pour le coup et là, pas question de faire une boucle, chaque bloc se positionne à un endroit précis.

bah pour le coup je suis bien content de bosser avec, en fait...j'ai eu besoin de générer un arbre à partir d'une table du même genre, et effectivement sans connect by/start with c'était casse-burnes.

[offtopic]

I love this guy ...
[/offtopic]

 
Ouais c'etait pas pour "optimiser" que je parlais en CSS, c'est juste pour le coté "on peut envoyer le code de l'arbre colonne par colonne" ce qu'on ne peut pas faire avec le tableau Vu que l'arbre aurait été généré par colonne avec la méthode 1generation->1requète c'aurait pu être pratique.

Ha oky, je vois ce que tu veux dire.

zavez lu mon truc ?
 
 

SELECT id WHERE idpapa=42 or idmaman=42
et t'aura tous les fils de 42 ( bon si c'est un male ou une femelle tu peut virer la moitié de la requète évidemment )

J'ai peut-être trouver une solution, je vous tiens au courant.

Bon, voilà ma solution, je n'ai pas encore "bencher" pour voir si elle était valable, elle impose une requête MySQL en plus (0,02s. via phpmyadmin) de plus mais m'évite de faire ma boucle qui prend tant de temps :
 

 
Et ça fonctionne impeccable, reste plus qu'à voir si j'y gagne en temps par rapport à ma grosse boucle.

Bon, j'ai benché et j'ai modifié en conséquence.
 
Alors finalement, on oublie la première requête, je fais quelquechose comme ça :

 
J'ai les résultats suivant par en comparant à ma routine habituel de boucle de tableau :
0.278538942337
0.666013002396  
 
C'est déjà de la bonne optimisation des familles.
 
(le temps de génération est fait sur un vieux PC où tourne tout un tas de truc, ça va généralement beaucoup plus vite sur mon serveur dédié).
 
Bon, reste plus qu'à mettre ça en place.

t'es pas obligé d'utilliser un for
 
tu peux boucler sur un while et affecter ta variable $i dans la boucle, ça devrait être un chouilla plus rapide

Je gagne entre 0.03 et 0.07s.
 
Par contre, tu me confirmes que le mysql_data_seek ça prend que dalle en temps machine ou je bench ?

avec un traitement, c'était plus rapide chez moi, sans traitement  kif-kif
 
du coup tu peux virer ton mysql_num_rows puisque $i prendra la valeur en sortie de while()

Voilà le code source de mysql_data_seek (MySql 4.0.27) :

 
Un p'tit for, deux p'tits trucs... Autrement dit, vraiment que dalle

Bah, le mysql_num_rows, ça me sert à avoir le nombre total de chien, maintenant, si tu me dis que ça va énormément moins vite qu'un count($row_lig), je le vire, je suis pas contrariant et je te fais confiance.
 
 

Bon, je comprends pas tout, mais si tu me dis "vraiment que dalle", ça me va.
 
 
Bon, reste plus qu'à appliquer ça sur toutes les pages du WikiPedi, ça va être costaud.