Här komemr frågan lite mer utbenad än igår.. Tjena, vad du kan göra är att sätta en join till din egen tabell. Du måste då ge denna tabell ett alias. har redan tänkt på det, men det ger mig ingen möjlighet att tala om vart jag vill starta min element tråd.. Vilket ID som skall vara styrande .. tjena igen, Tjena Litet tips som har för och nackdelar är att använda Null eller sitt eget id för att ange att det ska vara root objekt. Tjena Mitt förslag är nog att använda ett index fält som uppdateras med triggers. hmm som jag ser det kommer fortfarande en WHERE sats att döda den joinen .. jag kan ju ha 30 föräldrar i en tabell och vill bara kunan välja en av dem och des underligande barn / barnbarn / osv ... Hierakisk data
Har en tabell med två (fler men två fält är viktigast) fält.
ID | ParentID
ID är id't på ett inlägg och parentid är id't på det förmodade meddeladet man svara på .
ett typiskt scenario följer:
1) användare a lägger in ett huvudelement, parentid för detta är 0 och id 1
2) användare b skapar ett under element , parent id blir då 1 och id 2
3) användare c skapae också ett underelement, parent id 1 och id 3
4) användare d skapar ett underelement till element c, parent id 3 och id 4
då får vi en struktur som ser ut ungefär så här:
MSGA
|_ B
|_ C
|_D
tabellen säger:
ID | ParentID
1 0
2 1
3 1
4 3
Nu vill jag genom att ställa en sql fråga, kunna få upp en hel element struktur. Dvs jag vill kunna säga hämta element id 1. Vilket skall returnera element 1 och all dess underelement ur en hierakisk struktur..
Har tittat på joins och ms datashape, men kan inte rikitgt knäcka denna ... Sv: Hierakisk data
SELECT tblElement.ElementId, tblElement.InläggText, tblElement_1.ParentElementId
FROM tblElement INNER JOIN tblElement AS tblElement_1 ON tblElement.ParentElementId = tblElement_1.ParentElementId
GROUP BY tblElement.ElementId, tblElement.Inlägg, tblElement_1.ParentElementId
\PeterSv: Hierakisk data
Sv: Hierakisk data
så här borde sql:en se ut istället. Med denna får du ju fram vilket inlägg som är parentinlägget och sedan vilka inlägg som ligger under denna.
SELECT tblElement.ElementId, tblElement.ParentElementId, tblElement.Inlägg, tblElement_1.Inlägg
FROM tblElement LEFT JOIN tblElement AS tblElement_1 ON tblElement.ParentElementId = tblElement_1.ElementId
GROUP BY tblElement.ElementId, tblElement.ParentElementId, tblElement.Inlägg, tblElement_1.Inlägg
Tabell tblElement
ElementId ParentElementId Inlägg
1 Huvud
2 1 svar på huvud
3 1 svar på huvud[2]
4 3 svar på svar 3
5 3 svar på svar 3[2]Sv: Hierakisk data
Det beror på vilken databas du har.. Är det så att du kör Oracle så har du funktionen CONNECT BY som fixar det där åt dig.. I SQL Server går det att lösa med stored procedures med det är inte att rekommendera om recursionen har mer än 5-6 nivåer... Den bästa och snabbaste lösningen för SQL Server eller Access är en function som fixar recursionen åt dig...
Lycka till..Sv: Hierakisk data
Fördelar:
+ Du kan då implementera referensintegritet
+ Vilket innebär att du kan lägga till Cascad Delete
Nackdelar:
- ADO find och filter kan inte söka på null eller ett anat fält namn
Kom gärna med synpunkter på det här.Sv: Hierakisk data
Jag skulle sätta rootobjektets parent id till NULL och samt referensintegritet på fältet, men sedan i SELECT-satsen göra om det till 0 med hjälp av SQL Server funktionen ISNULL (finns säkert något liknande i Access) för att kunna använda ADO:s funktioner..
MickeSv: Hierakisk data
Eventuellt två fält:
* Ett som anger sorterings ordning, Index.
* Ett som anger nivå, Indent.
Vilket borde göra att fråger som ställs mod tabellen utför snabbt. Men de är ju också beroende på hur mycket som infogas läggs till och hur många index det finns på tabellen.Sv: Hierakisk data
Jag har löst det på ett annat sätt nu, har ännu ett fält med en ThreadID som talar om vem som är urfader till ett element .. genom att göra en enkel select på bara den kolumnen blir det både enklare och, med om indexering av tabellen, snabbare ..
Tack i alla fall ..
// Patrik