2010-12-06 6 views
0

Dans la requête ci-dessous, il y a un champ appelé main qui est utilisé pour différencier les catégories. Ainsi, il existe des catégories communes et des catégories principales et les deux peuvent être trouvés sur un arbre. Le champ main est juste un type et il n'y a rien avec l'arborescence, je veux dire, c'est comme un champ de statut.Comment changer ce CROSS JOIN SQL créé pour une traversée d'arbre (ensemble imbriqué)?

SELECT `c`.*, 
      (count(p.id)-1) AS `depth` 
     FROM `categories` AS `c` 
    CROSS JOIN `categories` AS `p` 
    WHERE (c.lft BETWEEN p.lft AND p.rht) 
     AND (c.root_id =p.root_id) 
     AND (p.main =1) 
    GROUP BY `c`.`id` 
    ORDER BY `c`.`root_id` ASC, `c`.`lft` ASC 

Il y a une clausule where qui précisent que la catégorie parente doivent être une catégorie principale. Aussi, parfois je dois faire un select où la catégorie parente est une catégorie commune p.main =0. La position depth est la position de l'élément dans l'arborescence. Donc, si une catégorie est un niveau enfants d'un autre, la profondeur sera 1, si deux niveaux, la profondeur sera 2.

Mon problème est que quand je fais la sélection ci-dessus, s'il y a des enfants marqués comme catégorie commune sur un arbre où le père est une catégorie principale (sélection p.main =1) les catégories communes depth est toujours 0. En d'autres termes, la sélection fonctionne correctement, si je sélectionne toutes les catégories ayant le parent supérieur marqué main, l'arborescence sera affichée avec toutes les catégories, y compris les catégories enfants marquées main=0. Mais dans ce cas, la profondeur est toujours 0

Voir les résultats:

alt text

La catégorie 1423 est un enfant de 27 et n'est pas une catégorie principale, mais 27 est, si la profondeur est 0 , mais doivent être 1. La catégorie 276 est un enfant de 64 et les deux sont des catégories principales, donc il a la bonne profondeur.

Comment puis-je modifier cette requête afin que le champ depth fonctionne comme prévu?

Référence ici: How to generate a tree view from this result set based on Tree Traversal Algorithm?

+0

Les mots 'ensemble imbriqué' aideraient ici. – ijw

+0

@ijw a changé ... –

+0

Voulez-vous que 'depth' soit égal au nombre d'ancêtres que cet élément a? Voulez-vous que cela fonctionne uniquement pour les nœuds ayant un ancêtre qui est un nœud "principal"? Voulez-vous que cela ne compte que les ancêtres «principaux»? Parce que c'est difficile à dire à partir de votre question. – ijw

Répondre

0

Vous dites en fait, vous êtes à la recherche de ce chef d'accusation, mais seulement pour les nœuds quels sont les enfants d'un parent principal. Si c'est ce que vous voulez vraiment, votre requête est plus erronée que de simplement corriger cela - la table que vous appelez 'p' et qui semble penser est une table 'parent' est en réalité une table 'ancêtre' - de même que 'c' n'est pas enfant mais 'descendant'. Vous finissez par compter les main ancêtres de tous les nœuds de l'arbre.

+0

Je n'ai pas compris. Tout fonctionne de manière prolifique lorsque toutes les catégories impliquées sont principales ou communes. Pouvez-vous clarifier? Il y a une croix joindre avec le groupe par. Ainsi, le compte fonctionne même si la catégorie n'a pas d'enfants. Et oui, le parent est l'ancêtre et non un parent principal. Le dépôt principal a un autre but. C'est comme un type. –