[MySQL] Count van children in zelfde resultset

Pagina: 1
Acties:

  • RwD
  • Registratie: Oktober 2000
  • Niet online

RwD

kloonikoon

Topicstarter
Ik probeer momenteel in 1 query te pakken te krijgen of in een menuustructuur de opgevraagde nodes in een MySQL resultset ook child elementen hebben, en ik kom er even niet uit.
code:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
------+--------+--------------
catid | parent | naam
------+--------+--------------
   1  |    0   | Eten
   2  |    1   | Groenten
   3  |    1   | Fruit
   4  |    2   | Spruitjes
   5  |    2   | Witlof
   6  |    2   | Spinazie
   7  |    3   | Appels
   8  |    3   | Peren
   9  |    3   | Bananen
  10  |    3   | Druiven
  11  |    7   | Elstar
  12  |    7   | Granny Smith
------+--------+--------------
(ik heb deze tabel overigens gepikt uit een ander topic omdat
 die precies in mn probleemomschrijving past)

Dat levert dus de volgende boomstructuur op:
code:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
Eten
  |
  +- Groenten
  |    |
  |    +-- Spruitjes
  |    |
  |    +-- Witlof
  |    |
  |    +-- Spinazie
  |
  |
  +-- Fruit
        |
        +-- Appels
        |     |
        |     +-- Elstar
        |     |
        |     +-- Granny Smith
        |
        +-- Peren
        |
        +-- Bananen
        |
        +-- Druiven

Nu heb ik het db ontwerp niet genormaliseerd, en het heeft vrij minimalistische trekjes, als data ergens afgeleid kan worden staat het dus niet in een veld in de db
En nu wil ik graag dus in 1 query bijvoorbeeld de child elementen voor 'Fruit' ophalen, en meteen een veld in de resultset hebben 'has_child'.
De resultset zou dus de volgende zijn:
code:
1
2
3
4
5
6
7
8
------+--------+----------+--------------
catid | parent | haschild | naam
------+--------+----------+--------------
   7  |    3   |     1    | Appels
   8  |    3   |     0    | Peren
   9  |    3   |     0    | Bananen
  10  |    3   |     0    | Druiven
------+--------+----------+--------------

Dit krijg ik echter niet voor mekaar op MySQL 4.0.18 :(
Ik kan geen subqueries gebruiken; ik had gedacht aan iets als
SQL:
1
2
3
4
5
6
7
8
SELECT catid
,      parent
,      naam
,      (SELECT COUNT(catid)
        FROM   category c2
        WHERE  c2.parent = c1.category_id) as haschild
FROM   category
WHERE  category = '3'
Maar dat mag niet, in ieder geval niet met die versie MySQL. Dus heb ik verder nog wat loze pogingen gehad waarvan de queries weinig interressant zijn.
Is het überhaubt wel te doen in 1 query?

Mijn oplossing in een (beschamende) oudere oplossing was gewoon alle parent op te halen in een array te zetten en later te checken of een cat_id in het array voorkomt (en dus een parent is). Echter, dan haal ik altijd 1000 parents meer op dan nodig, voor iedere keer dat 1 van de 1000 parents geopend wordt....
Die oplossing was overigens best ok in die oudere oplossing, omdat ik toen de gehele boomstructuur op haalde *schaam* bij elke page reload.

Kan iemand me in de goede richting wijzen??

  • djluc
  • Registratie: Oktober 2002
  • Laatst online: 23-05 14:53
Je kan eventueel ook de Celko techniek gebruiken. Die is hier erg handig voor.

  • RwD
  • Registratie: Oktober 2000
  • Niet online

RwD

kloonikoon

Topicstarter
djluc schreef op 23 augustus 2004 @ 11:21:
Je kan eventueel ook de Celko techniek gebruiken. Die is hier erg handig voor.
Euhm, ik kom er niet meteen uit, probeer hem nu uit te vogelen. Maar ik zie wel dat ik daarvoor 2 1 kolommen meer nodig heb dan nu. Mits ik de parent omtover tot Qty. En ik wil graag dezelfde layout houden omdat ik anders veel meer stukken zou moeten herschrijven.

Edit:
Ik wil dus graag de layout houden zoals die is. Het probleem moet toch met een query op te lossen zijn lijkt me.

Edit:
Ik ben er uit hoe Celko in mekaar zit.
Op zich een leuk idee; je kunt aan het verschil tussen lft en rgt zien of er kinderen onder hangen. Helaas wil ik de db structuur niet veranderen omdat ik dan in de bijbehorende objecten moet gaan lopen aanpassen en tig queries aan moet passen waar ik liever 1 query aanpas.

Edit:
Even mijn bewering boven in deze post aangepast die klopte niet

[ Voor 43% gewijzigd door RwD op 23-08-2004 14:02 ]