[PHP] Optimale afhandeling geneste replies

[Verwijderd]

Hoi

Ik ben een reply-systeem aan het bouwen vergelijkbaar met dat op de t.net frontpage. Dat betekent dus ook geneste replies, zoals:

code:

Reply 1
|- reply 2
|--|- reply 5
|- reply 4
Reply 3
|- Reply 6

Ik hoop dat dat een beetje duidelijk is. Goed, in de database heb ik dus een Reply ID en een Parent ID. De Parent ID wijst naar de 'bovenliggende' reply.

Mijn huidige implementatie gaat ongeveer zo:
- foreach reply
- display reply
- check for childs
- display child

Dat betekent dus dat bij flink geneste replies er een hoop keer door de hele reply-array wordt heengelopen. Ik vraag me af of dit netter / efficienter kan, en daarvoor vraag ik jullie hulp en inzicht.

Alvast bedankt!

[Verwijderd]

Afhankelijk van het aantal te verwachten replies kun je dit beter oplossen door in één keer alle replies op te vragen met een enkele query, en dan met PHP de sortering te doen. Als je ook de diepte van de nestingopslaat kun je het sorteren efficiënter doen.

Eventueel kun je ook voor MPTT gaan.

[Verwijderd]

Verwijderd schreef op zaterdag 25 november 2006 @ 14:45:
Afhankelijk van het aantal te verwachten replies kun je dit beter oplossen door in één keer alle replies op te vragen met een enkele query, en dan met PHP de sortering te doen.

Dat doe ik nu ook, min of meer.

$replies = sql_poly('SELECT * FROM `replies` where `type` = '.(int)$type.' GROUP BY `id`');
Dus alle replies komen in $replies en dan gaat het:

foreach ($replies as $reply)
displayreply($reply);

Die displayreply functie kan zichzelf aanroepen als hij een 'child' tegenkomt, maar in die functie wordt dus ook met foreach de hele array weer doorgelopen, dus dat is eigenlijk gekkenwerk. Nu is PHP wel redelijk snel maar ik kan me voorstellen dat dit niet optimaal werkt, temeer omdat ik wil dat mijn pageviews snel zijn, het inserten van een reply mag best wat langer duren.

Als je ook de diepte van de nestingopslaat kun je het sorteren efficiënter doen.

Hoe gebruik ik dat dan? De diepte opslaan in de database van elke reply?

Ik had trouwens nog een ander idee: een PHP array zoals:

$replystruct = array( 1 => array( 2 => array(4 => ''), 3 => ''), 5 => array(6 => '') )

Dus dan krijg je iets als:

$replystruct[1]
$replystruct[1][2]
$replystruct[1][2][4]
$replystruct[1][3]
$replystruct[5]
$replystruct[5][6]
etc.

Voordeel is dat ik kan doen:

foreach ($replies as $replyid => $childs)
..processreply..

De replystruct kan ik dan serialized opslaan en snel gebruiken voor pageviews, en de struct update ik zodra een nieuwe reply wordt gepost. Wat denken jullie?

[djc]

Verwijderd schreef op zaterdag 25 november 2006 @ 14:45:
Eventueel kun je ook voor MPTT gaan.

Dat artikel is vrij geniaal, dat zou ik sowieso even lezen. Lijkt me makkelijker dan zelf iets klussen.

[Verwijderd]

Manuzhai schreef op zaterdag 25 november 2006 @ 19:47:
[...]
Dat artikel is vrij geniaal, dat zou ik sowieso even lezen. Lijkt me makkelijker dan zelf iets klussen.

Dat recursieve algoritme op die page is wat ik nu heb, ongeveer. Alleen wat ik wel vaag vind is dat hij tijdens die loop elke keer een query trekt. Dat kun je beter in de hoofdfunctie doen en dan global $replies maken zodat de recursiefunctie niet elke keer zelf iets uit de database moet trekken. Maargoed wel interessant artikel om mijn gedachte recursief te kunnen ordenen.

_{En leuk jou ook te zien op GoT!}

[djc]

Verwijderd schreef op zaterdag 25 november 2006 @ 20:53:
Dat recursieve algoritme op die page is wat ik nu heb, ongeveer. Alleen wat ik wel vaag vind is dat hij tijdens die loop elke keer een query trekt. Dat kun je beter in de hoofdfunctie doen en dan global $replies maken zodat de recursiefunctie niet elke keer zelf iets uit de database moet trekken. Maargoed wel interessant artikel om mijn gedachte recursief te kunnen ordenen.

Alleen de eerste pagina gelezen? Lees even door!

[Verwijderd]

Manuzhai schreef op zondag 26 november 2006 @ 00:19:
[...]
Alleen de eerste pagina gelezen? Lees even door!

Al gedaan, maar ik vind dat MPTT maar omslachtig. Het is wel handig als je een branch/tak wilt hebben en je dan heel snel kunt uitrekenen welke items je dan uit de DB moet trekken, maar in mijn geval wil ik ze allemaal weergeven. Ik ben nu in de weer met een 'depth' recursief algoritme, wat volgens mij redelijk snel is.
In elk geval maar 1 query.

[frickY]

Alles willen weergeven is toch het zelfde als de branche/tak van de root-node?

Artikel ziet er interessant uit, briljante oplossing. In de praktijk alleen wat omslachtiger om toe te passen.

[MisterData]

Ik gebruik MPTT ook in een CMS, maar dan wel gecombineerd met de 'gewone' parent_id structuur ernaast. Wil je álle children gebruik je MPTT, wil je children van één object dan doe je een simpele parent_id select

[Verwijderd]

frickY schreef op zondag 26 november 2006 @ 10:22:
Alles willen weergeven is toch het zelfde als de branche/tak van de root-node?

Ja dat is ook zo, maar dat is wel het grote voordeel van dit algoritme denk ik, dat je via MySQL via "left" en "right" variabelen dus een branch kunt selecten. Voor mij speelt dat niet mee.

Zijn recursie algoritme kan nog veel verbeterd worden, dus uiteindelijk ben ik daarvoor gegaan. Maar het is wel interessant om dat MPTT eens te lezen, misschien gebruik ik het nog wel eens.

Het performance-verlies van mijn huidige recursieve algoritme kan ik ook slim wegwerken met behulp van caching, waarbij de cache wordt ververst zodra er op die page een nieuwe reply wordt aangemaakt. Zodoende zijn pageviews dus heel snel en duren de posts ietsje langer.