Tjenare.

Googlat sönder internet i hopp om att hitta en smart lösning för att få rekursiva querys och hierarktisk datastruktur att gå ihop.

Exempel på hierarktisk datastruktur är ett träd med parent, child, grandchild-objekt, grandgrandchild etc. så kallad The Adjacency List Model:

Parent
Child
GrandChild
Child
GrandChild
GrandGrandChild
GrandChild

Detta är bra att kunna skapa om man gör ett kommenteringssystem där man kan svara på kommentarer. Alltså att alla objekt är kommentarer.

För att lagra detta så tänkte jag att Child har ett parent_id-attribut som pekar på ID:t till parent för detta objekt. Problemet är att mysql inte har stöd för hierarktisk data när det gäller querys. MSSQL och Oracle har stöd för detta. Med stöd så menar jag, att kunna lista trädet i rätt ordning.

Det enklaste sättet jag vet (efter eget testande) är att spara ett slags indenteringsnummer för varje inlägg där istället för ett parent_id så har man indentation_number. Exempelvis:

1 Parent
1.1 Child
1.1.1 GrandChild
1.1 Child
1.1.1 GrandChild
1.1.1.1 GrandGrandChild
1.1.1 GrandChild

Ex: Om man vill svara på kommentaren Parent så skickas 1 med, och Child lägger på 1 = 1.1
Vill man svara på Child så skickas 1.1 med och GrandChild lägger på 1 = 1.1.1
För att lösa problemet om vilket objekt som skall komma först i listan sorteras det på datum.

Detta system fungerar, men det är synd att behöva strukturera om allt vid byte av databas. Självklart kan man göra sorteringslogiken i applikationskoden (PHP, C#, etc) men enligt mina principer så ska databasen göra allt sånt arbete...

Min fråga efter detta långa inlägg: Finns det någon som har lyckats göra en mysql-query som kan presentera en Adjacency List (parent/child-träd) på rätt sätt? MySQLs egna förslag är helt åt skogen:
http://dev.mysql.com/tech-resources/articles/hierarchical-data.html

Har inte lyckats hitta någon best practice för detta vilket är kasst.

För det första: "Hierarkisk", inget "t".

Trädstrukturer har ju mängder med lösningar. Först och främst har du ju den vanliga;
ID, ParentID, OrderIndex, Info

Som har just det problemet du nämner - även om den är logisk när det kommer till att representera data och sätta in data är den hemskt ologisk när det kommer till att plocka ut data och ta bort data eller poster upp och ner.

I ditt fall låter du ju OrderIndex vara datum, och därmed är det lätt att ta bort och flytta enskilda poster.

Och då kommer vi ju till precis det du har konstaterat, att man kan behöva sortera grejerna i kod. Dina principer stämmer inte överens med mina - jag ser det inte som ett stort problem att ta ut det och hantera det i kod. Det beror ju på hur man vill visa det - ibland kanske man snarare vill ha hela grejen i datumordning och på något annat sätt indikera vilken som är parent?
Eller visa det som ett faktiskt träd, eller någon annan galen idé.

Själv föredrar jag att fylla objekt med informationen och sen mata ut dem.

MySQLs exempel behöver annars inte vara så dumt, det är ganska lätt att bygga upp sqlkoden dynamiskt så att man får ut det så.


Sen finns det ju vidare flera andra typer av strukturer. Har du ett fast maxdjup (vilket kanske inte är en så dum ide) kan du ju göra ett antal tabeller Comment1->CommentN (spontant känns det inte så snyggt men är egentligen rätt vetttigt)

Annars har du flera andra strukturer och hybrider. En klassisk som jag glömt namnet på har istället två räknare som "följer med trädet", och som ger trädet depth-first med en enda fråga.
(EDIT: modified preorder tree traversal alt. nested set model kallas det och finns också med under "The Nested Set Model" i det dokumentet du länkade till.)

Stämmer bra det, hierarkisk ska det vara.

Jag ser det inte heller som ett stort problem att hantera det i kod men i detta fall känns det som ett nödvändigt ont.
Jag skulle inte säga att det beror på hur man vill visa det. En query för olika visningstyper, skulle jag göra. Självklart kan man göra det i kod. Alla är vi olika. :)

Att fylla objekt (eller inte) från en query ur en struktur likt "adjacency list"-modellen går utmärkt, då är det egentligen bara fler, mindre querys, som bildar trädet istället för en all-in-one. Lagrade procedurer som gör hela trädet åt en, och sköter sorteringen, går det med. Men lagrade procedurer har jag fått lite svårt för med tanke på att logiken följer databasen inte applikationen.

Jag får nöja mig med det jag har och jag tackar för svaret.

Från SQL Server 2005 kan man lösa många hierarkiska problem med CTE:s :)
Annars är väl det klassiska i detta fall två val:
- Stored proc som har en loop / en cursor som bygger upp en tmp-tabell i minnet
(det går väl även i MySql?)
- I kod bygga objektträd som redan har föreslagits