[MySql] Query om lineare conversatie op te halen

[Verwijderd]

Hallo mensen,
wie kan mij in de goede richting helpen, ik heb een tabel met daarin 3 velden:
id, onderwerp, parent ...

Parent verwijst naar het ID van een bovenliggend bericht.

Nu wil ik dus met 1 query, alle berichten (meest recente) in de juiste volgorde selecteren, en ik weet niet hoe ik dit zo moet doen, het is namelijk een soort van join, die X keer gedaan moet worden, op zn eigen tabel ...
Wie kan mij in de goede richting helpen?

[Avalaxy]

Kan dat niet gewoon met een simpele ORDER BY?

SQL:

SELECT *
FROM tabelnaam
ORDER BY `parent` DESC

[TweakBoy]

een beetje dit idee dus: http://dev.mysql.com/tech...es/hierarchical-data.html

[Verwijderd]

Als je inderdaad alle berichten wil hebben kun je zoals Avalaxy zegt gewoon de hele tabel selecteren en dan ordenen op ID (niet op parent), of, beter, op een nieuw datum/tijd-veld. Je kunt beter niet op de primaire sleutel vertrouwen als je wil ordenen op tijd. Daar gebruik je liever gewoon een datum/tijd veld voor, bijvoorbeeld 'create_date'..

Op Sitepoint staat trouwens ook een goed artikel over het managen van hierarchische data in een tabel. Handig voor als je alleen bepaalde subtrees op wil pakken, of als je de diepte van een bepaald record in de boom wil bepalen, et cetera..

http://blogs.sitepoint.com/hierarchical-data-database/

[Camulos]

Wat de TS vraagt kan niet met SQL en zijn tabel ^^
SQL kent niet echt hierarchische structuur, dit kun je beter afvangen in je code.

Mocht je toch een 2-level sql-output willen, dan zul je gebruik moeten maken van de group-by clause en left-joins. Verder kun je het verfijnen door een strictere Select dan wel Group by te gebruiken

SQL:

SELECT *
FROM tabelnaam t1
LEFT JOIN tabelnaam t2 on t2.parent_id = t1.id
GROUP BY t1.id
ORDER BY t1.id DESC

Je krijgt dan alle resultaten van de tabel waarbij de hoogste ID als eerste terug komt. Daarnaast join je de tweede tabel alleen als er een overeenkomstige parent-child relaties zijn.
Let op dat alleen gegroepeerd wordt op de T1-id

Voorbeeld tabel:
ID :: Desc :: Parent_id
1 , a , null
2 , b , 1
3 , c , 1
4 , d , null

Door de join en slechts group-by op 1 element krijg je een output ala

t1.id

t1.description

t1.parent_id

t2.id

t2.description

t2.parent_id

Dus schematische output:

4	d	null
1	a	null	2	b	1
	a	null	3	c	1

[lier]

Kan je niet iets met een cursor en een loop?
Welke versie van MySQL wordt gebruikt?

[Voutloos]

KISS en doe het niet met SQL maar met een redelijk triviale recursieve functie: Crisp's blog: Formatting a multi-level menu using only one query

[Reinier]

Camulos schreef op woensdag 13 april 2011 @ 08:11:

SQL:

SELECT *
FROM tabelnaam t1
LEFT JOIN tabelnaam t2 on t2.parent_id = t1.id
GROUP BY t1.id
ORDER BY t1.id DESC

Dat is niet heel netjes. Groeperen op 1 veld zonder aan te geven wat er met de overige velden moet gebeuren = niet doen. MySQL slikt het, maar het is onjuist.

[gertvdijk]

Voutloos schreef op woensdag 13 april 2011 @ 09:08:
KISS en doe het niet met SQL maar met een redelijk triviale recursieve functie: Crisp's blog: Formatting a multi-level menu using only one query

Dat voorbeeld is leuk voor een tiental of honderdtal rows in je tabel, maar wordt lastiger wanneer het om > duizenden gaat, aangezien hij door alle rows heen loopt.

[Verwijderd]

Heb jullie antwoorden nog niet bekeken, maar de link van TweakBoy lijk ik het meest aan te hebben.

Ik draai overigens MySQL 5.1.56, en het gaat om een tabel met tien, mischien wel honderdduizenden rows ... maar, het aantal rows moet niet uit mogen maken, de tabel groeit namelijk erg hard...

[Verwijderd]

Ok, even ingelezen in de antwoorden, het lijkt dus niet te kunnen met mijn huidige tabelstructuur, wat raden jullie dan aan? Zie mijn probleem als dit topic, berichten, lineair onder elkaar ... hoe word dit gedaan?

[Voutloos]

Hier zie je enkel berichten van 1 topic en dat filtert wel zo lekker. Wellicht wel leuk om een topic-achtige entity te introduceren, of desnoods een topParentID kolom.

[Verwijderd]

Het gaat ook om 1 topic, ik heb in mijn query reeds het id, van het meest recente bericht ... en vanuit dat bericht moet de hiërarchie worden opgebouwd

[Voutloos]

En je topic heeft honderdduizenden berichten?

[/slowchat, probeer/test anders gewoon iets, of kom in 1x met de info]

[ Voor 43% gewijzigd door Voutloos op 13-04-2011 11:11 ]

[Verwijderd]

Ok de info:
Het zijn topics, die gemiddels 50 replies hebben ... dit kunnen in sommige gevallen er stukken meer zijn.
Ik wil de query gebruiken, om 1 thread weer te geven, querys om de topic weer te geven, of het laatste bericht heb ik wel...
Ging mij nu dus, om met 1 query, zo netjes mogelijk, een linieare weergave van het topic te genereren, vanuit het laatste bericht...

[ Voor 4% gewijzigd door Verwijderd op 13-04-2011 11:21 ]

[ajakkes]

Een lineare topic met een auto-increment kan je toch prima sorteren op ID. Heb je geen parent voor nodig. Je zegt zelf dat het 1 topic is. Desnoods voeg je er een datum aan toe voor de volgorde. Of een simpel volgorde veld.

Ik dacht in eerste instantie dat het om een boom structuur ging. Die maakt het iets lastiger maar als de lengte van de takken beperkt is valt het ook wel mee.


Edit:
Als reactie op je laatste bericht
Voeg een topic ID toe. En selecteer daarop.

[ Voor 10% gewijzigd door ajakkes op 13-04-2011 11:25 ]

[Verwijderd]

In de tabel staat niet 1 topic, maar meerdere ...
Voorbeeld:

ID	Inhoud	parent
1	Dit is een topic	0
2	Dit is een 2e topic	0
3	Dit is een reply op topic 1	1
4	Dit is een reply op de reply	3

Er word altijd gereplyd op t laatste bericht in de desbetreffende thread...
Of kan ik beter dan het ID van de Root node opslaan in het parent veld, ipv het voorgaande bericht?
Ik gebruik het parent veld namelijk ook om te kijken of het laatste bericht al beantwoord is.. maar dat kan ook in laatst genoemde mogelijkheid bedenk ik me nu

[ Voor 13% gewijzigd door Verwijderd op 13-04-2011 11:35 ]

[ajakkes]

Voeg een topicId toe. Of gebruik je parentId zoals jij voorsteld om naar de root te verwijzen en zie je root als topicId.

[remco_k]

^^ Precies.

Dan wordt het dus:

ID	Inhoud	parent	topicId
1	Dit is een topic	0	2000
2	Dit is een 2e topic	0	2065
3	Dit is een reply op topic 1	1	2000
4	Dit is een reply op de reply	3	2000

Waar je nu op moet selecteren lijkt me duidelijk.

De recursieve manier die Voutloos (cq Crisp) aanvoert werkt ook prima. Als je tenminste niet al te grote tabellen hebt. Voor een menu structuur die toch altijd in z'n geheel opgevraagd moet worden, is het een prima oplossing die ik ook gebruik om categorie structuren op te vragen.

Het nadeel daarvan is wel dat als de tabel duizenden records heeft, de code ze ook allemaal selecteerd in de query en daarna doorloopt, terwijl je misschien maar een topic van 3 records nodig hebt. Dan gaat het (te) traag worden vanwege de grote hoeveelheid overhead. Vandaar dat ik een voorstander ben van de topicId oplossing.

[ Voor 41% gewijzigd door remco_k op 13-04-2011 11:51 ]

[Verwijderd]

Dan kan net zo goed de parent vervallen, en sorteren op ID, er zijn geen geneste antwoorden mogelijk (het is een conversatie, geen forum-achtige constructie)

[remco_k]

(ik had nog wat ge-edit in de tussentijd)
Als je toch al niet kon of wil nesten dan kan je de parent gewoon gebruiken voor dit doel natuurlijk.
Maar misschien voor de toekomst is het bestaan van parent zoals het nu is wel een wenselijk veld om te zien op welk bericht iemand een antwoord stuurde.
Ik zou parent zo laten en topicId toevoegen. Parent zit je niet in de weg wat dat betreft.

[ Voor 19% gewijzigd door remco_k op 13-04-2011 11:50 ]

[ajakkes]

Zo zie je maar weer dat in je topic start de juiste informatie geven heel erg kan helpen met het snel oplossen van je problemen.
Bij parentId's wordt er eigenlijk al snel vanuit gegaan dat er een hiërarchie structuur is. (Dat een parent meerder childs kan hebben). Dat zie je terug in de eerste reacties. Maar in je topic titel stond wel al dat het om lineaire data ging.
Het probleem dat je omschrijft is een heel bekend probleem bij parents met meerdere children. Maar heel simpel met lineaire data.

[Verwijderd]

Ok, in ieder geval allen bedankt! Het probleem is soms even moeilijk verwoorden