MySQL Nested Sets: nur direkte Nachfahren in einem Query?

[WhiZZler]

begrüße!

ich beschäftige mich grade mal wieder ein wenig mit nested sets und schönen bäumen..

ich möchte zu einer id nur die direkten nachfahren auslesen.. dafür habe ich folgenden query gebaut:

SELECT 
  COUNT(root.process_id) AS `level`, `node`.`process_id`, 
  `node`.`lft`, `node`.`rgt`,  ROUND((node.rgt - node.lft - 1)/2) AS `num_childs`

FROM 
  `process` AS `parent` 
CROSS JOIN 
  `process` AS `root` 
CROSS JOIN 
  `process` AS `node` 

WHERE 
  (node.lft > root.lft AND node.lft < root.rgt) 
AND 
  (node.lft > parent.lft AND node.lft < parent.rgt) 
AND 
  (parent.process_id = 1) AND (node.is_active = 1) 

GROUP BY `node`.`lft` 
ORDER BY `node`.`lft` ASC

damit bekomme ich alle daten wie gewünscht.. aber ich bekomme auch alle kinder zu dem knoten.. ich möchte aber nur die direkten nachfahren und nicht die kindeskinder (sagt man das so bei bäumen? )

im prinzip muss man den query ja nur um einen having teil erweitern.. also

HAVING level = (parent_level + 1)

das problem ist aber, dass ich irgendwie nich draufkomme, wie ich ohne extra query an den parent_level rankomme.. mit parent_level meine ich einfach den level des elternelements, zu dem die direkten nachfahren ausgelesen werden sollen..
habe jede möglich art von id mit und ohne distinct gezählt und habe keine brauchbaren ergebnisse erhalten..

hat jemand ne idee?

mfg
whizzler

 

[ice-breaker]

bei solchen Problemen wird die Speicherung des Baumes in MySQL meist um solch eine Level-Funktion erweitert
Also dass jeder Datensatz nun auch ein level-Attribut hat

 

[WhiZZler]

bei solchen Problemen wird die Speicherung des Baumes in MySQL meist um solch eine Level-Funktion erweitert
Also dass jeder Datensatz nun auch ein level-Attribut hat

klingt einfach aber logisch

nachteil ist dann eben, dass beim eintragen, verschieben und löschen von nodes neben dem lft und rgt wert auch noch der level berichtigt werden muss..

aus performance sicht ist es aber wohl sinnvoller.. ich werde es aber trotzdem erstmal bei dem extra query belassen.. wenn es nötig ist wird es nachimplementiert..