---

Hej NG !

Jeg udvikler på et forum der lavet i php. Alle indlæg i forummet gemmes i en
mySql tabel. Trådene i forummet er kædet sammen ved hjælp af rootID og
parentID. Altså hvert indlæg har et unikt rootID. Når dette indlæg besvares
så tildeles svarindlægets parentid værdien af id fra det indlæg der svares
på.

Det jeg har brug for at lave er en liste med alle startindlæg, som er
sorteret således at det indlæg der sidst er besvaret skal stå øverst på
listen.

Mit spørgsmål er nu hvordan min SQL skal se ud. Jeg ved så meget at jeg skal
trække de rækker ud hvor parentID=0 da det er alle med startindlæg. Men
hvordan får jeg det sorteret i den rigtige rækkefølge ???

--
Mvh
Michael Hansen

---

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

"Michael Hansen" <michael@amweb.dk> writes:

> Det jeg har brug for at lave er en liste med alle startindlæg, som er
> sorteret således at det indlæg der sidst er besvaret skal stå øverst på
> listen.

Du tænker nok i den forkerte retning, altså på at starte med
rodbeskeden. Start i stedet med den nyeste besked, hvorfra du så kan
finde roden, altså noget i stil med

SELECT r1.ID FROM tabel AS r0, tabel AS r1 WHERE r0.rootID = r1.ID
ORDER BY r1.posttime DESC

Jeg ved ikke, om MySQL kan klare dette pga. sin ukomplette
understøttelse af SQL, men ellers skulle du nok kunne bruge det som
udgangspunkt.

Håber det hjælper.

Martin

- --
Homepage: http://www.cs.auc.dk/~factotum/
GPG public key: http://www.cs.auc.dk/~factotum/gpgkey.txt
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: Using Mailcrypt+GnuPG <http://www.gnupg.org>

iEYEARECAAYFAj4DHKwACgkQYu1fMmOQldWcaQCgvADv1Gj45NAbMjxUgyMgQmX6
bl8AoOig9TpGr/jk+zLt7gVe62pux3YO
=NY9+
-----END PGP SIGNATURE-----

---

"Martin Christensen" <knightsofspamalot-factotum@gvdnet.dk> wrote in message
news:87fzssvmmr.fsf@gvdnet.dk...
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> "Michael Hansen" <michael@amweb.dk> writes:
>
> > Det jeg har brug for at lave er en liste med alle startindlæg, som er
> > sorteret således at det indlæg der sidst er besvaret skal stå øverst på
> > listen.
>
> Du tænker nok i den forkerte retning, altså på at starte med
> rodbeskeden.

Deri tager du sandsynligvis fejl.

Medmindre du kan lave super avanceret SQL er det altså rodbeskeden man
starter med og henter den første besked der peger på den, derefter den der
peger på den osv.

Rekursivitet programmeres ikke i SQL men i det bagvedliggende scriptsprog.


> Jeg ved ikke, om MySQL kan klare dette pga. sin ukomplette
> understøttelse af SQL, men ellers skulle du nok kunne bruge det som
> udgangspunkt.

Hvordan er dens implementering "ukomplet"?

Mvh
Jimmy

---

> Rekursivitet programmeres ikke i SQL men i det bagvedliggende scriptsprog.

Joh, i Oracle kan man lave denne røver:

SELECT
beskedid, besked
FROM
tabel
CONNECT BY PRIOR
beskedid = parentid

Jeg er lidt rusten, så det kan være at det ikke er HELT nøjagtigt, men ideen
er den samme...

-
Lars
http://coder.dk/sohofaq.php - Uofficiel WOL SOHO 77 FAQ
To mail me remove your pants.

---

Jimmy skrev:

>> Jeg ved ikke, om MySQL kan klare dette pga. sin ukomplette
>> understøttelse af SQL,...

> Hvordan er dens implementering "ukomplet"?

Subselects er en væsentlig mangel (findes vist i nyere mySQL'er,
men sjældent i de versioner der stilles spørgsmål om her .

For nylig har manglen på views også været omtalt (så vidt jeg
husker er views også standard-SQL)
--
Jens Gyldenkærne Clausen
MF (medlem af FIDUSO - www.fiduso.dk)
I ovenstående tekst benyttes nyt komma.

---

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

"Jimmy" <spoerg@efter.den> writes:

>> Du tænker nok i den forkerte retning, altså på at starte med
>> rodbeskeden.
>
> Deri tager du sandsynligvis fejl.
>
> Medmindre du kan lave super avanceret SQL er det altså rodbeskeden
> man starter med og henter den første besked der peger på den,
> derefter den der peger på den osv.

Man skal først kende den korrekte rodbesked, og den skal i dette
tilfælde findes uden kendskab til hvilken rodbesked, den hører til.
Den fædrende rodbesked skal altså først findes, hvorefter man så kan
hente alt under den. Her havde subqueries gjort, at man kunne nøjes
med en enkelt forespørgsel i stedet for to, se nedenfor.

> Rekursivitet programmeres ikke i SQL men i det bagvedliggende
> scriptsprog.

Som allerede nævnt kan Oracle håndtere rekursive
forespørgsler. Alternativt kan man bruge stored procedures. Forresten
behøver du ikke at bruge al for megen tid på at forklare mig det
grundlæggende; jeg er ved at skrive speciale i databaser.

>> Jeg ved ikke, om MySQL kan klare dette pga. sin ukomplette
>> understøttelse af SQL, men ellers skulle du nok kunne bruge det som
>> udgangspunkt.
> Hvordan er dens implementering "ukomplet"?

Øh... det troede jeg da, var almindeligt kendt. Der mangler
eksempelvis understøttelse for bl.a. subqueries, views, foreign keys
og flere grundlæggende ting, og det er først for nyligt, at
transactions er kommet med i den stabile version. ACID-egenskaberne
har altid været vigtige krav til DBMS'er, men MySQL har taget lidt let
på dem, nok mest fordi brugerbasen har brugt den til ting, hvor det
ikke har været så væsentligt.

Martin

- --
Homepage: http://www.cs.auc.dk/~factotum/
GPG public key: http://www.cs.auc.dk/~factotum/gpgkey.txt
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: Using Mailcrypt+GnuPG <http://www.gnupg.org>

iEYEARECAAYFAj4FfvgACgkQYu1fMmOQldXvlwCeMzlFsN0R0ort5sOQth6yufZk
318AoIZsDIZVMT99wSEc2sHE+mexkqqf
=oGtA
-----END PGP SIGNATURE-----

---

"Martin Christensen" <knightsofspamalot-factotum@gvdnet.dk> wrote in message
news:87y96i77k7.fsf@gvdnet.dk...
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> "Jimmy" <spoerg@efter.den> writes:
>
> >> Du tænker nok i den forkerte retning, altså på at starte med
> >> rodbeskeden.
> >
> > Deri tager du sandsynligvis fejl.
> >
> > Medmindre du kan lave super avanceret SQL er det altså rodbeskeden
> > man starter med og henter den første besked der peger på den,
> > derefter den der peger på den osv.
>
> Man skal først kende den korrekte rodbesked, og den skal i dette
> tilfælde findes uden kendskab til hvilken rodbesked, den hører til.
> Den fædrende rodbesked skal altså først findes, hvorefter man så kan
> hente alt under den. Her havde subqueries gjort, at man kunne nøjes
> med en enkelt forespørgsel i stedet for to, se nedenfor.


Hvordan løser den problemet med at første besked har et svar, som har et
svar, som har et svar, som har et svar osv?


> > Rekursivitet programmeres ikke i SQL men i det bagvedliggende
> > scriptsprog.
>
> Som allerede nævnt kan Oracle håndtere rekursive
> forespørgsler.

Kan den klare ovenstående?


> Alternativt kan man bruge stored procedures. Forresten
> behøver du ikke at bruge al for megen tid på at forklare mig det
> grundlæggende; jeg er ved at skrive speciale i databaser.

Jeg bilder mig ikke ind jeg ved mere end dig, men dine udsagn strider imod,
hvad jeg på nuværende tidspunkt tror jeg ved
Jeg vil gerne forbeholde mig retten til at stille opklarende spørgsmål.


> >> Jeg ved ikke, om MySQL kan klare dette pga. sin ukomplette
> >> understøttelse af SQL, men ellers skulle du nok kunne bruge det som
> >> udgangspunkt.
> > Hvordan er dens implementering "ukomplet"?
>
> Øh... det troede jeg da, var almindeligt kendt. Der mangler
> eksempelvis understøttelse for bl.a. subqueries, views, foreign keys
> og flere grundlæggende ting, og det er først for nyligt, at
> transactions er kommet med i den stabile version. ACID-egenskaberne
> har altid været vigtige krav til DBMS'er, men MySQL har taget lidt let
> på dem, nok mest fordi brugerbasen har brugt den til ting, hvor det
> ikke har været så væsentligt.

Enig - Ovennævnte ting ville være rart at have.

Jeg tilhører web-programmørerne, hvor disse ting ofte kan undværes.

Jeg er også af den holdning, at jeg er mere tilgivende overfor et system,
der er gratis og samtidig virker enormt godt.
Min pointe er, at MySQL ikke implementerer en feature før de _ved_ den
virker.
Med andre ord - Det, der er, virker.

Mvh
Jimmy

---

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

"Jimmy" <spoerg@efter.den> writes:

>> Man skal først kende den korrekte rodbesked, og den skal i dette
>> tilfælde findes uden kendskab til hvilken rodbesked, den hører til.
>> Den fædrende rodbesked skal altså først findes, hvorefter man så
>> kan hente alt under den. Her havde subqueries gjort, at man kunne
>> nøjes med en enkelt forespørgsel i stedet for to, se nedenfor.
> Hvordan løser den problemet med at første besked har et svar, som
> har et svar, som har et svar, som har et svar osv?

Det oprindelige spørgsmål sagde højt og tydeligt, at der blev gemt
referencer til forælderindlægget _og_ rodindlægget. Derfor er det ikke
nødvendigt med en rekursiv forespørgsel.

>> Som allerede nævnt kan Oracle håndtere rekursive forespørgsler.
> Kan den klare ovenstående?

Det går jeg ud fra. Jeg ved ærligt talt ikke særligt meget om det, da
jeg ikke er den store Oracle-haj, men ellers kan det laves med stored
procedures, som MySQL dog ikke understøtter.

> Jeg bilder mig ikke ind jeg ved mere end dig, men dine udsagn
> strider imod, hvad jeg på nuværende tidspunkt tror jeg ved
> Jeg vil gerne forbeholde mig retten til at stille opklarende
> spørgsmål.

Ja da, ingen problemer. Jeg havde bare indtryk af, at du troede, jeg
var nybegynder, så jeg ville spare dig det eventuelle besvær med at
skære tingene ud i pap. Det krudt er bedre brugt andetsteds, er jeg
sikker på.

>> Øh... det troede jeg da, var almindeligt kendt. Der mangler
>> eksempelvis understøttelse for bl.a. subqueries, views, foreign keys
>> og flere grundlæggende ting, og det er først for nyligt, at
>> transactions er kommet med i den stabile version. ACID-egenskaberne
>> har altid været vigtige krav til DBMS'er, men MySQL har taget lidt let
>> på dem, nok mest fordi brugerbasen har brugt den til ting, hvor det
>> ikke har været så væsentligt.
> Enig - Ovennævnte ting ville være rart at have.
> Jeg tilhører web-programmørerne, hvor disse ting ofte kan undværes.

Yep, lige nøjagtigt MySQLs fanskare, og det er udelukket (vil jeg
gætte på) denne gruppe der har gjort, at MySQL har kunnet overleve i
den form, man ser i dag.

> Jeg er også af den holdning, at jeg er mere tilgivende overfor et system,
> der er gratis og samtidig virker enormt godt.
> Min pointe er, at MySQL ikke implementerer en feature før de _ved_ den
> virker.
> Med andre ord - Det, der er, virker.

For mig betyder frihed meget mere end lav eller ikke-eksisterende
pris, omend de ofte følges ad. Sammenligner man MySQL med PostgreSQL,
er den sidste meget, meget mere feature-komplet, og den er så afgjort
ikke ustabil på nogen måde. Det er mit indtryk, at den kan alt det,
som MySQL kan samt meget mere, og performancemæssigt er de
sammenlignelige på nær et enkelt punkt: ved mange samtidige
forbindelser dør MySQL meget hurtigere end de fleste andre RDBMS'er,
mens PostgreSQL holder til et langt større pres. (Til gengæld har
PostgreSQL et problem med VACUUM, som kan være træls for databaser,
der er belastede 24 timer i døgnet.) Som altid kan man finde
benchmarks, der viser, at den ene er hurtigere end den anden til dette
eller hint, men her er de ikke størrelsesordner fra hinanden i det
store hele, så vidt jeg ved. Altså virker PostgreSQL lige så godt som
MySQL, men der er de forskellige features ikke sparet væk, eller
hvordan man nu rationaliserer MySQL-folkenes valg.

Martin

- --
Homepage: http://www.cs.auc.dk/~factotum/
GPG public key: http://www.cs.auc.dk/~factotum/gpgkey.txt
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: Using Mailcrypt+GnuPG <http://www.gnupg.org>

iEYEARECAAYFAj4F4ZMACgkQYu1fMmOQldXP0ACgvMPZqxbVH7XhbApc5jnNZoRs
37YAn2m8GdEa9FneV/Hz9T9tBt9oFFkm
=VC43
-----END PGP SIGNATURE-----

---

"Martin Christensen" <knightsofspamalot-factotum@gvdnet.dk> wrote in message
news:87bs3e6o30.fsf@gvdnet.dk...
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> "Jimmy" <spoerg@efter.den> writes:
>
> >> Man skal først kende den korrekte rodbesked, og den skal i dette
> >> tilfælde findes uden kendskab til hvilken rodbesked, den hører til.
> >> Den fædrende rodbesked skal altså først findes, hvorefter man så
> >> kan hente alt under den. Her havde subqueries gjort, at man kunne
> >> nøjes med en enkelt forespørgsel i stedet for to, se nedenfor.
> > Hvordan løser den problemet med at første besked har et svar, som
> > har et svar, som har et svar, som har et svar osv?
>
> Det oprindelige spørgsmål sagde højt og tydeligt, at der blev gemt
> referencer til forælderindlægget _og_ rodindlægget. Derfor er det ikke
> nødvendigt med en rekursiv forespørgsel.

Jeg er ikke enig i din fortolkning.

1)
Spørgeren angiver han skal lave et forum.
Et forum, hvor man kun kan svare på hovedindlæg er ikke et forum.

Spørgeren siger:

"Altså hvert indlæg har et unikt rootID. Når dette indlæg besvares
så tildeles svarindlægets parentid værdien af id fra det indlæg der svares
på."

2)
Et indlæg har sit eget unikke ID (rootID)
Indlæg har et "parentid", som indeholder rootID på det indlæg det er svar
på.

Der er derfor behov for rekursivitet, som jeg ikke mener din løsning
opfylder.


> >> Som allerede nævnt kan Oracle håndtere rekursive forespørgsler.
> > Kan den klare ovenstående?
>
> Det går jeg ud fra. Jeg ved ærligt talt ikke særligt meget om det, da
> jeg ikke er den store Oracle-haj, men ellers kan det laves med stored
> procedures, som MySQL dog ikke understøtter.

Ja ok :-/

Som tidligere nævnt mener jeg ikke man kan løse spørgerens problem vha. ren
SQL.

Jeg er af den opfattelse, at man skal løse opgaven rekursivt, og lade det
bagvedliggende scriptsprog håndtere rekursiviteten.

Mvh
Jimmy

---

Jimmy skrev:

[Martin Christensen]
>> Det oprindelige spørgsmål sagde højt og tydeligt, at der blev
>> gemt referencer til forælderindlægget _og_ rodindlægget.
>> Derfor er det ikke nødvendigt med en rekursiv forespørgsel.

> 1)
> Spørgeren angiver han skal lave et forum.
> Et forum, hvor man kun kan svare på hovedindlæg er ikke et
> forum.

Det er der vist ingen der har påstået.
Martin skriver (så vidt jeg læser det) at der for alle indlæg
gemmes to nøgleværdier fra andre indlæg: rootID og parentID.

> Spørgeren siger:
>
> "Altså hvert indlæg har et unikt rootID. Når dette indlæg
> besvares så tildeles svarindlægets parentid værdien af id fra
> det indlæg der svares på."

>
> 2)
> Et indlæg har sit eget unikke ID (rootID)

Det kan du ikke slutte ud af ovennævnte citat. Der er tre mulige
id-felter: rootID (id-nummeret på første indlæg i en tråd),
parentID (id på moderindlægget) og messageID (id på det aktuelle
indlæg). For at lave et forum med trådning skal mindst to af
felterne være oprettet.
Spørgeren har ikke fortalt hvilke id-felter forummet indeholder -
det ville afklare en del hvis det kom frem.

> Indlæg har et "parentid", som indeholder rootID på det indlæg
> det er svar på.

Jeg opfatter "rootID" som en reference til det øverste indlæg i en
tråd. Du opfatter det som primærnøglen i tabellen. Kun spørgeren
kan vide hvem der har ret.
--
Jens Gyldenkærne Clausen
MF (medlem af FIDUSO - www.fiduso.dk)
I ovenstående tekst benyttes nyt komma.

---

"Jens Gyldenkærne Clausen" <jens@gyros.invalid> wrote in message
news:Xns92ECEFD3A7BCEjcdmfdk@gyrosmod.cybercity.dk...
> Jimmy skrev:
>
> [Martin Christensen]
> >> Det oprindelige spørgsmål sagde højt og tydeligt, at der blev
> >> gemt referencer til forælderindlægget _og_ rodindlægget.
> >> Derfor er det ikke nødvendigt med en rekursiv forespørgsel.
>
> > 1)
> > Spørgeren angiver han skal lave et forum.
> > Et forum, hvor man kun kan svare på hovedindlæg er ikke et
> > forum.
>
> Det er der vist ingen der har påstået.

Jo - Det har jeg

> Martin skriver (så vidt jeg læser det) at der for alle indlæg
> gemmes to nøgleværdier fra andre indlæg: rootID og parentID.

Enig - Det er svært at tyde ud fra det oprindelige indlæg, hvad der er hvad.
Jeg blander min egen opfattelse ind for at forstå indlægget.

Dog vil jeg mene at Martins ide om at det står "højt og tydeligt" ikke er
korrekt, da vi tydeligvis har divergerende opfattelser.


> Spørgeren har ikke fortalt hvilke id-felter forummet indeholder -
> det ville afklare en del hvis det kom frem.

Enig!

> > Indlæg har et "parentid", som indeholder rootID på det indlæg
> > det er svar på.
>
> Jeg opfatter "rootID" som en reference til det øverste indlæg i en
> tråd. Du opfatter det som primærnøglen i tabellen. Kun spørgeren
> kan vide hvem der har ret.

Jamen lad os da høre fra ham

Mvh
Jimmy

---

>SNIP>
> Jamen lad os da høre fra ham
>
Ok her kommer lidt, forhåbentlig, opklarende info om de id der gemmes til
hvert indlæg:

rootID : Unikt id for det enkelte indlæg.
parentID : Refererer til moder-indlæget. Altså det _første_ indlæg i tråden.

Dvs alle indlæg i databasen har et parentID pånær "moder-indlæg" som har
værdien 0 i parentID.
Forummet vises ikke grafisk som tråde men istedet cronologisk med
moder-indlæget øverst og followups listet under dette. Altså lidt i stil med
phpBB-forummet.

Det jeg så vil er at trække alle moder-indlæg ud af databasen (parentID=0).
De skal så sorteres således at det moder-indlæg der sidst er besvaret står
øverst.

--
Mvh
Michael Hansen

---

"Michael Hansen" <michael@amweb.dk> wrote in message
news:3e0724a8$0$1737$d40e179e@nntp03.dk.telia.net...

>
> rootID : Unikt id for det enkelte indlæg.
> parentID : Refererer til moder-indlæget. Altså det _første_ indlæg i
tråden.

OK - Svar på underindlæg vil ligne svar på hovedindlæg.

rootID ville jeg nok kalde ID - Det gør man typisk, når det, den i
virkeligheden gør, er at pege på en unik række i en tabel.

Jeg mener, at det er decideret forkert at kalde det for Parent_ID, hvis den
ikke peger på sin umiddelbare Parent. Jens?

Jeg ville finde et andet udtryk for dette, men have tre kolonner, så du ikke
begrænser dig selv når du en dag i fremtiden ønsker at tråde det som på en
nyhedsgruppe.

ID - Unikt ID - Definineret som AUTO_INCREMENT
Root_Message_ID - Fremmednøgle, der peger på hovedindlæggets ID (Er der ikke
et ofte anvendt ord for dette?)
Parent_ID - Fremmednøgle, der peger på den besked der reelt besvares.

Hvorfor går jeg så op i noget, som Michael sikkert synes er bagateller og
intet har med funktionalitet at gøre?

Ganske enkelt fordi de begreber han har valgt at anvende har nogle
specifikke konnotationer, som gør det svært for udenforstående at forstå
hans kode/opbygning.


> Det jeg så vil er at trække alle moder-indlæg ud af databasen
(parentID=0).
> De skal så sorteres således at det moder-indlæg der sidst er besvaret står
> øverst.

Så mener jeg de forslag du har fået tidligere burde virke helt fint.

Mvh
Jimmy

---

<SNIP>
> OK - Svar på underindlæg vil ligne svar på hovedindlæg.

Hvem har sagt at svar på underindlæg er muligt i dette tilfælde ??

> rootID ville jeg nok kalde ID - Det gør man typisk, når det, den i
> virkeligheden gør, er at pege på en unik række i en tabel.

Kan der være noget om

> Jeg mener, at det er decideret forkert at kalde det for Parent_ID, hvis
den
> ikke peger på sin umiddelbare Parent. Jens?

Øhhh jamen det er jo netop det den gør.
ALLE svar der postes er UDELUKKENDE til moderindlæget. Og set i lyset af det
så synes jeg da det ligger meget natuligt at kalde den parentID, ik ?!?

> Jeg ville finde et andet udtryk for dette, men have tre kolonner, så du
ikke
> begrænser dig selv når du en dag i fremtiden ønsker at tråde det som på en
> nyhedsgruppe.

"Forummet" skal 100% sikkert aldrig laves om til trådvisning da dette slet
ikke passer ind. Der svares jo KUN på moderindlæget, så hvad skulle ideen
med tråde være ???

> Hvorfor går jeg så op i noget, som Michael sikkert synes er bagateller og
> intet har med funktionalitet at gøre?

Spøgsmålet var jo aldrig ment som en debat om kodeetik !! Jeg går selv
rigtig meget op i at kommentere min kode især når jeg ifm mit arbejder laver
projekter hvor vi er flere programmører der arbejder på samme kode. Men i
dette tilfælde er det et privat projekt som aldrig vil havne i hænderne på
andre en mig selv.
Derfor irriterer det mig at når man stiller et spørgsmål i en nyhedsgruppe,
så skal man lige have 100 svar med belærende ord og løftede pegefingre inden
der endelig er en person der svarer på det konkrete spørgsmål.
Om jeg kalder et felt for rootID eller ID har da så absolut intet at betyde
for hvordan SQL'en skal opbygges for at opnå den ønskede funktionalitet som
jeg oprindelig spurgte efter.

--
Mvh
Michael Hansen

---

"Michael Hansen" <michael@amweb.dk> wrote in message
news:3e09f72f$0$24678$d40e179e@nntp02.dk.telia.net...
> <SNIP>

> Derfor irriterer det mig at når man stiller et spørgsmål i en
nyhedsgruppe,
> så skal man lige have 100 svar med belærende ord og løftede pegefingre
inden
> der endelig er en person der svarer på det konkrete spørgsmål.

Jeg skal hermed gerne undlade at forsøge på at hjælpe dig yderligere.
Held og lykke med dit projekt.

Mvh
Jimmy

---

<SNIP>
>
> Jeg skal hermed gerne undlade at forsøge på at hjælpe dig yderligere.
> Held og lykke med dit projekt.

Ahhh ok Jimmy, kan godt se at tonen i mit indlæg måske ikke var helt sober.
Så det har du har du hermed min uforbeholdte undskyldning for. Det var på
ingen måde min mening at svine dig til !

Jeg har nu ændret tabellen således at rootID nu hedder ID og er unik for
hvert indlæg. ParentID refererer til "moderindlæget", og der kan kun svares
på moderindlæget.

Håber stadig du vil hjælpe og ikke bærer alt for meget nag.

--
Mvh
Michael

---

> Øhhh jamen det er jo netop det den gør.
> ALLE svar der postes er UDELUKKENDE til moderindlæget. Og set i lyset af
det
> så synes jeg da det ligger meget natuligt at kalde den parentID, ik ?!?

det er jo misvisende. læs dog hva jimmi skriver!!!!


> > Jeg ville finde et andet udtryk for dette, men have tre kolonner, så du
> ikke
> > begrænser dig selv når du en dag i fremtiden ønsker at tråde det som på
en
> > nyhedsgruppe.
>
> "Forummet" skal 100% sikkert aldrig laves om til trådvisning da dette slet
> ikke passer ind. Der svares jo KUN på moderindlæget, så hvad skulle ideen
> med tråde være ???
>
> > Hvorfor går jeg så op i noget, som Michael sikkert synes er bagateller
og
> > intet har med funktionalitet at gøre?
>
> Spøgsmålet var jo aldrig ment som en debat om kodeetik !! Jeg går selv
> rigtig meget op i at kommentere min kode især når jeg ifm mit arbejder
laver
> projekter hvor vi er flere programmører der arbejder på samme kode. Men i
> dette tilfælde er det et privat projekt som aldrig vil havne i hænderne på
> andre en mig selv.

hvad snakker du om?? du har da lige snedt det i hænderne på i hvertfald tre
andre som ikk ehar fattet hvad din "kode" gik ud på fordi du har vedtaget
din egen navnekonvention.

er det de tre der er dumme eller dig der ikke fatter at skrive så man kan
forstå det????

> Derfor irriterer det mig at når man stiller et spørgsmål i en
nyhedsgruppe,
> så skal man lige have 100 svar med belærende ord og løftede pegefingre
inden
> der endelig er en person der svarer på det konkrete spørgsmål.

tror du usenet KUN er til for dig??
nyhed - det er til for alle!!!

> Om je

g kalder et felt for rootID eller ID har da så absolut intet at betyde
> for hvordan SQL'en skal opbygges for at opnå den ønskede funktionalitet
som
> jeg oprindelig spurgte efter.

du har ikke spurgt om noget konkret. du har lavet egen navnekonvention som
har gjort det umuligt for tre folk at forstå dig og nu svarer du grimt. tror
du selv du når langt med den strategi????

du er da en utaknemmelig person som ikke fik nok gaver igår hva??

jesper


>
> --
> Mvh
> Michael Hansen
>
>

---

<SNIP>
> > Derfor irriterer det mig at når man stiller et spørgsmål i en
> nyhedsgruppe,
> > så skal man lige have 100 svar med belærende ord og løftede pegefingre
> inden
> > der endelig er en person der svarer på det konkrete spørgsmål.
>
> tror du usenet KUN er til for dig??
> nyhed - det er til for alle!!!

Jeg har brugt usenet i MANGE år, og JA jeg ved da godt det ikke kun er for
mig ! Virkede det som om jeg troede noget andet ??
Men når diskusionen nærmer sig offtopic så må jeg da godt irreterere mig. Ok
jeg kan så godt se at tonen ikke var særlig sober og det har jeg da så også
beklaget over for Jimmy.

> g kalder et felt for rootID eller ID har da så absolut intet at betyde
> > for hvordan SQL'en skal opbygges for at opnå den ønskede funktionalitet
> som
> > jeg oprindelig spurgte efter.
>
> du har ikke spurgt om noget konkret. du har lavet egen navnekonvention som
> har gjort det umuligt for tre folk at forstå dig og nu svarer du grimt.
tror
> du selv du når langt med den strategi????

Har jeg ikke spurgt om noget konkret ?? Hvaa har du læst hele tråden ? Er
nedenstående ikke konkret nok ??
**CITAT***
Mit spørgsmål er nu hvordan min SQL skal se ud. Jeg ved så meget at jeg skal
trække de rækker ud hvor parentID=0 da det er alle med startindlæg. Men
hvordan får jeg det sorteret i den rigtige rækkefølge ???
***********
Egen navnekonvention ??
Måske lidt en overdrivelse, men ok rootID skulle måske være ID.

---

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

"Jimmy" <spoerg@efter.den> writes:

>> Det oprindelige spørgsmål sagde højt og tydeligt, at der blev gemt
>> referencer til forælderindlægget _og_ rodindlægget. Derfor er det
>> ikke nødvendigt med en rekursiv forespørgsel.
> Jeg er ikke enig i din fortolkning.

Nu kommer jeg også i tvivl om, hvordan det skal læses.

"Trådene i forummet er kædet sammen ved hjælp af rootID og
parentID. Altså hvert indlæg har et unikt rootID. Når dette indlæg
besvares så tildeles svarindlægets parentid værdien af id fra det
indlæg der svares på."

Jeg læste det således, at rootID pegede på det første indlæg i en
given tråd. Denne opfattelse fik jeg fra kolonnens navn. Hvad skulle
'root' ellers hentyde til? Men ved nærmere læsning er der ikke andet
der tyder på, at det forholder sig således, og jeg må derfor bøje mig.

En reference til rodindlæget ville dog kunne sætte fart på mange
forespørgsler. Da denne information kan udledes af den øvrige
information i tabellen, ville det være muligt at ændre en eventuelt
eksisterende database til at inkludere denne information, hvorved man
kan spare sig selv for en masse arbejde.

> Der er derfor behov for rekursivitet, som jeg ikke mener din løsning
> opfylder.

Nej, det må jeg give dig ret i, men i stedet for at føje
omstændighederne, vil jeg nærmere mene, at omstændighederne skal
ændres.

> Som tidligere nævnt mener jeg ikke man kan løse spørgerens problem
> vha. ren SQL.

Det kunne der måske være noget om, i hvert fald hvis vi taler om
SQL92.

> Jeg er af den opfattelse, at man skal løse opgaven rekursivt, og
> lade det bagvedliggende scriptsprog håndtere rekursiviteten.

Den er jeg nu ikke for glad for. Et begrænset antal forespørgsler fra
front-enden til back-enden er som regel altid at foretrække. Antallet
af forespørgsler kunne dog reduceres til dybden af den længste 'gren'
plus det løse, givet vi har et ID på roden. Det kunne gøres noget i
stil med,

(lidt pseudo...)

SELECT INTO TEMPORARY TABLE t FROM indlæg WHERE id = [rodid]

while antal returnerede tupler > 0
SELECT indlæg.* INTO TEMPORARY TABLE t FROM indlæg, t
WHERE indlæg.parentID = t.id

SELECT * FROM t
DROP TABLE t

Så kunne resten af logikken ordnes i scriptsproget, som du
efterlyser. Hvis hvert enkelt indlæg havde reference til roden, ville
en enkelt forespørgsel kunne klare det. Hvis indlæggene desuden er
ordnede, fx på timestamps, kan man desuden drage nytte af det, når man
opbygger hierarkiet af indlæg: opfatter vi tråden som et træ, vil
hvert enkelt indlægs forælder allerede være i træet, og generering af
træet vil derfor være O(n), hvorimod en uordnet følge af indlæg nok
ikke kunne opbygges til et træ hurtigere end O(n^2).

Martin

- --
Homepage: http://www.cs.auc.dk/~factotum/
GPG public key: http://www.cs.auc.dk/~factotum/gpgkey.txt
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: Using Mailcrypt+GnuPG <http://www.gnupg.org>

iEYEARECAAYFAj4GRmcACgkQYu1fMmOQldVraACePedW5tOR2iJA8cSBSgpLDTto
EOkAoKgVkY/ivGXZ9Oqi0elAV6sWl4MV
=HSEJ
-----END PGP SIGNATURE-----

---

<SNIP>
> Jeg læste det således, at rootID pegede på det første indlæg i en
> given tråd. Denne opfattelse fik jeg fra kolonnens navn. Hvad skulle
> 'root' ellers hentyde til? Men ved nærmere læsning er der ikke andet
> der tyder på, at det forholder sig således, og jeg må derfor bøje mig.

Der kan kun svares på det første indlæg. Alle svar på dette "moderindlæg"
har en parentID der refererer til moderindlægets rootID. Dette rootID er
måske lidt misvisende. Skulle nok nærmere bare hedde ID.

--
Mvh
Michael

---

Michael Hansen <michael@amweb.dk> skrev i en
nyhedsmeddelelse:3e09f8cd$0$24679$d40e179e@nntp02.dk.telia.net...
> <SNIP>
> > Jeg læste det således, at rootID pegede på det første indlæg i en
> > given tråd. Denne opfattelse fik jeg fra kolonnens navn. Hvad skulle
> > 'root' ellers hentyde til? Men ved nærmere læsning er der ikke andet
> > der tyder på, at det forholder sig således, og jeg må derfor bøje mig.
>
> Der kan kun svares på det første indlæg. Alle svar på dette "moderindlæg"
> har en parentID der refererer til moderindlægets rootID. Dette rootID er
> måske lidt misvisende. Skulle nok nærmere bare hedde ID.

du bliver ved hva??
først sviner du jimmi til og derefter bruger du halvdelen af hans
information!!!

godt jeg ikke arbejder sammen med dig eller har noget med dig at gøre!!!

jesper

>
> --
> Mvh
> Michael
>
>

---

<SNIP>
> > Der kan kun svares på det første indlæg. Alle svar på dette
"moderindlæg"
> > har en parentID der refererer til moderindlægets rootID. Dette rootID er
> > måske lidt misvisende. Skulle nok nærmere bare hedde ID.
>
> du bliver ved hva??

Hvad er der nu galt med det jeg har skrevet her ???

> først sviner du jimmi til og derefter bruger du halvdelen af hans
> information!!!

Her forstår jeg da SLET ikke hvad du mener !
Som svar til Martin Cristensen prøver jeg bare at forklare ham det som han
bad uddybet. Hvad er der galt i det ?

> godt jeg ikke arbejder sammen med dig eller har noget med dig at gøre!!!
Nå nå så drejer du debatten over til at være personlig ! Iøvrigt så synes
jeg da ikke selv du opfører dig meget bedre. Synes du nærmer dig noget der
hører til i dk.snak.mudderkastning !

--
Mvh
Michael

---

Jesper Poulsen skrev:

[Michael Hansen (MH)]
>> Der kan kun svares på det første indlæg. Alle svar på dette
>> "moderindlæg" har en parentID der refererer til
>> moderindlægets rootID. Dette rootID er måske lidt misvisende.
>> Skulle nok nærmere bare hedde ID.
>
> du bliver ved hva??

Der er da ikke noget galt med
<news:3e09f8cd$0$24679$d40e179e@nntp02.dk.telia.net> (det indlæg du
lige har svaret på).

MH's indlæg fra 25. december, 19:19
(<news:3e09f72f$0$24678$d40e179e@nntp02.dk.telia.net>) var ikke så
smart formuleret - hvad der da også er gjort opmærksom på. Derimod
er det der er citeret øverst i dette indlæg både relevant for
tråden og skrevet i en sober tone.

> først sviner du jimmi til og derefter bruger du halvdelen af
> hans information!!!
>
> godt jeg ikke arbejder sammen med dig eller har noget med dig
> at gøre!!!

Selvom MH begyndte er det altså ikke ensbetydende med at der er
grønt lys for at svine MH til.

To tekniske noter:
a) Du indleder dine svar med "Sv: " i stedet for "Re: ". Det er en
fejl der bl.a. bevirker at dit indlæg vil blive bortfiltreret af
visse newsservere. Når dit indlæg slipper igennem bevirker det et
emneskift som hos nogle brugere vil vises som en ny tråd. Hvis du
opgraderer dit usenetprogram skulle problemet løse sig selv -
ellers spørg i <news:dk.velkommen> eller
<news:dk.edb.internet.software.mail+news.outlook-express>

b) Klip venligst de linjer du ikke citerer væk inden du sender et
indlæg. Det er forvirrende når man ikke kan se hvornår dit indlæg
slutter.

FUT: dk.admin.netikette (svar på dette indlæg havner automatisk i
nævnte gruppe)
--
Jens Gyldenkærne Clausen
MF (medlem af FIDUSO - www.fiduso.dk)
I ovenstående tekst benyttes nyt komma.

---

Michael Hansen skrev:

> Spøgsmålet var jo aldrig ment som en debat om kodeetik !!

Men hvis en eller flere i gruppen tager emnet op i din debat har de
nu stadig lov til det (forudsat at kodeetik er indenfor gruppens
emnefelt).

> Men i dette tilfælde er det et privat projekt som aldrig vil
> havne i hænderne på andre en mig selv.

Det var måske hvad du havde tænkt - men du har jo sendt det til en
offentlig nyhedsgruppe hvor det er endt i hænderne på mange andre
end dig selv.


> Derfor irriterer det mig at når man stiller et spørgsmål
> i en nyhedsgruppe, så skal man lige have 100 svar med
> belærende ord og løftede pegefingre inden der endelig er en
> person der svarer på det konkrete spørgsmål.

Hvis du er irriteret over formen på usenet, så stil dine spørgsmål
et andet sted. På usenet hjælper folk af egen fri vilje - og ideen
er at man kan lære noget af hinanden. Hvis du bare vil have et svar
uden kommentarer er usenet ikke det rette forum.

> Om jeg kalder et felt for rootID eller ID har da så absolut
> intet at betyde for hvordan SQL'en skal opbygges for at opnå
> den ønskede funktionalitet som jeg oprindelig spurgte efter.

Nej - du kunne også kalde felterne for "felt1", "felt2", ... eller
"x", "y", "z", ... - og man ville stadig kunne lave en fuldt
funktionel database. Men din navngivning har stor betydning for
hvor nemt udenforstående, fx folk her i gruppen, har ved at forstå
hvilke data du gemmer "bag" navnene. Som du kan se af denne tråd
har der været en del forvirring omkring rootID og parentID - fordi
folk ikke har kunnet regne ud hvad de dækkede over. Hvis du fra
starten havde fortalt det havde alle deltagere i tråden sparet en
del tid og forvirring. Herunder er et forsøg på en kortfattet
forklaring. Det har taget mig tre minutter at skrive den - du burde
kunne gøre det mindst lige så hurtigt hvis det er dig selv der har
udviklet databasen.

,--------
| rootID (primærnøgle, id for et indlæg)
| parentID (fremmednøgle, 0 hvis indlægget er et rodindlæg, ellers
| id-værdien på det rod-indlæg indlægget er svar på)
| Forummet skal ikke vise indlæg i tråd, man skal bare kunne svare på
| indlæg i et niveau.
`--------
--
Jens Gyldenkærne Clausen
MF (medlem af FIDUSO - www.fiduso.dk)
I ovenstående tekst benyttes nyt komma.

---

<SNIP>
> Hvis du er irriteret over formen på usenet, så stil dine spørgsmål
> et andet sted. På usenet hjælper folk af egen fri vilje - og ideen
> er at man kan lære noget af hinanden. Hvis du bare vil have et svar
> uden kommentarer er usenet ikke det rette forum.

Ja du har selvfølgelig ret.
Tonen jeg gjorde brug af hørte på ingen måde hjemme på usenet. Det beklager
jeg.

> Nej - du kunne også kalde felterne for "felt1", "felt2", ... eller
> "x", "y", "z", ... - og man ville stadig kunne lave en fuldt
> funktionel database. Men din navngivning har stor betydning for
> hvor nemt udenforstående, fx folk her i gruppen, har ved at forstå
> hvilke data du gemmer "bag" navnene. Som du kan se af denne tråd
> har der været en del forvirring omkring rootID og parentID - fordi
> folk ikke har kunnet regne ud hvad de dækkede over. Hvis du fra
> starten havde fortalt det havde alle deltagere i tråden sparet en
> del tid og forvirring.

Den tager jeg på mig. Kan godt se at det er gået lidt for hurtigt da jeg
skrev startindlæget. Skulle have uddybet det lidt bedre hvad felterne betød.
Og efter denne debat så kan jeg da godt se at rootID ikke er så smart et
navn, men da jeg lavede databasen tænkte jeg ikke lige nærmere over det. Men
det har jeg ihvertfald ændret i tabellen nu.

> ,--------
> | rootID (primærnøgle, id for et indlæg)
> | parentID (fremmednøgle, 0 hvis indlægget er et rodindlæg, ellers
> | id-værdien på det rod-indlæg indlægget er svar på)
> | Forummet skal ikke vise indlæg i tråd, man skal bare kunne svare på
> | indlæg i et niveau.
> `--------
Ja det må siges at være præcis formuleret

--
Mvh
Michael