---

Jeg sidder lige nu og leger med at lave et forum i ASP.NET vha. C#, og da
jeg tidligere har fået "verbale tæsk" af Allan Ebdrup for at foreslå en
rekursiv løsning(i classic ASP) pga. de mange databaseopslag sad jeg lige og
kom til at tænke på noget:

Hvis jeg nu for hver tråd i min debat blot har en post i databasen med
følgende felter:


ThreadID
Subject
CreatedDate
UserID ( Relaterer til min brugertabel )

Udover dette skal der være et felt mere, som kan være en af to ting:

1. Et varchar felt med stien til en XML fil indholdene hele denne tråds
indlæg i "nested" form.
2. Et text felt indholdene XML'en til alle trådens indlæg i korrekt "nested"
form.

På denne måde kunne jeg spare flere database forespørgsler pr. tråd og det
rekursive vil blive varetaget af XSLT.

Nu sidder i nok og tænker hvor er det han har løbet hovedet mod muren, men
det har jeg faktisk ikke endnu det virker som om det performer rigtig godt,
og mit load på databasen er minimalt da jeg jo bruger et dataset (som jo er
en slags disconnected recordset) derfor ingen tur til databasen ved
sammenklapning af tråde.

Er der nogle der har nogle kommentarer til mine tanker, eller nogle der kan
se nogle problemer?
Hvad vil holde bedst at have mine tråede gemt i XML-filer eller lade XML'en
ligge i databasen?
Hvad er belastningen på webserveren ved at køre min XML og min XSLT sammen
på webserveren når jeg bruger en selvkaldende template i XSLT?

--
Jakob Andersen

---

"Jakob Andersen" <jakob@effectus.dk> wrote in message
news:aa1h2g$27i7$1@news.cybercity.dk...
> Jeg sidder lige nu og leger med at lave et forum i ASP.NET vha. C#, og da
> jeg tidligere har fået "verbale tæsk" af Allan Ebdrup for at foreslå en
> rekursiv løsning(i classic ASP) pga. de mange databaseopslag sad jeg lige
og
> kom til at tænke på noget:

Verbale tæsk er nu så meget sagt, konstruktiv kritik vil jeg kalde det

[klip]
> 1. Et varchar felt med stien til en XML fil indholdene hele denne tråds
> indlæg i "nested" form.
> 2. Et text felt indholdene XML'en til alle trådens indlæg i korrekt
"nested"
> form.
>
> På denne måde kunne jeg spare flere database forespørgsler pr. tråd og det
> rekursive vil blive varetaget af XSLT.
[klip]

Det kan du jo sagtens gøre, det du reelt gør er at denormalisere databasen
for at få performance, et godt gammelt trick. Faldgruberne er mange tænk
over hvad du vil gøre hvis:
1) Der slettes/arkiveres en besked i tråden (fx den første besked, eller en
midt i tråden).
2) Sorteringen skal laves om.
3) En bruger skifter navn
4) En besked får rettet sit "emne" (eng: Subject)
5) Enhver anden form for ret/slet/opret på enkelte dele af tråden.

Hvis du kan holde tungen lige i munden så kan det højst sandsynligt godt
lade sig gøre, for der er visse ting du ikke kan gøre effektivt med din
denormalisering af databasen, spørgsmålet er så om du får brug for dem
senere...

MVH
Allan Ebdrup
http://www.ti-fire.dk

---

"Allan Ebdrup" <ebdrup@ti-fire.dk> wrote in message
news:aa7456$2vll$1@news.cybercity.dk...
> Det kan du jo sagtens gøre, det du reelt gør er at denormalisere databasen
> for at få performance, et godt gammelt trick.

Om det så er godt kan jo diskuteres.

> 1) Der slettes/arkiveres en besked i tråden (fx den første besked, eller
en
> midt i tråden).

Dette viste sig at være det største problem, men vha. .NET's lækre XML/XPath
klasser har jeg fået lavet en rimelig effektiv løsning.

> 2) Sorteringen skal laves om.

Den har jeg ikke tænkt på endnu, men jeg tror ikke det bliver nødvendigt, da
jeg jo kan sortere starttrådene som jeg har lyst til.

> 3) En bruger skifter navn

Heldigvis har de brugere der skal bruge systemet at de faktisk helst vil
have brugernavne stå uberørte selvom det er ændret senere da dette er
"Historik". Hvis jeg ikke denormaliserer på dette punkt skal jeg alligevel
laven en userlog hvori man kan se hvornår en bruger skiftede navn.

> 4) En besked får rettet sit "emne" (eng: Subject)

Ikke noget problem. Det rettes hurtigt ved hjælp af en pænt effektiv
funktion jeg har fået lavet til at rette i de enkelte poster i mit XMLtræ

> 5) Enhver anden form for ret/slet/opret på enkelte dele af tråden.

Heller ikke dette er det store problem, det er godt nok performance
krævende, men det sker jo ikke så ofte.

> Hvis du kan holde tungen lige i munden så kan det højst sandsynligt godt
> lade sig gøre, for der er visse ting du ikke kan gøre effektivt med din
> denormalisering af databasen, spørgsmålet er så om du får brug for dem
> senere...

Faktisk var det noget af det mest basale man kan forestille sig der fik mig
til ikke at bruge dette system (ihvertfald lige pt.) nemlig visningen af det
enkelte indlæg: Denne handling bliver ret performance krævende da man skal
til at ind i sit XMLtræ for at finde den enkelte besked ved hver visning, og
da dette nok er et af de mest kritiske øjeblikke med henblik på hastighed og
ikke mindst belastning ville det simpelthen dræbe systemets ydeevne.

--
Jakob Andersen

---

"Jakob Andersen" <jakob@effectus.dk> wrote in message
news:aa76ll$1i5$1@news.cybercity.dk...
> "Allan Ebdrup" <ebdrup@ti-fire.dk> wrote in message
> news:aa7456$2vll$1@news.cybercity.dk...
> > Det kan du jo sagtens gøre, det du reelt gør er at denormalisere
databasen
> > for at få performance, et godt gammelt trick.
>
> Om det så er godt kan jo diskuteres.

Hej Jacob
Alt kan diskuteres, men denormalisering kan tit forbedre performance
drastisk og ofte uden at det gør den store forskel for databasemodellens
brugbarhed. Det er jo fx de færreste datamodeller der er på 5. Normalform
(eller højere). Ja faktisk er de færreste datamodeller på 3. Normalform.

Jeg forstår ikke dit problem med visning af det enkelte indlæg. Har du ikke
indlægets subject liggende i XML træet samt hele beskeden liggend i sin egen
tabel?

MVH
Allan Ebdrup

---

"Allan Ebdrup" <ebdrup@ti-fire.dk> wrote in message
news:aacfto$1l4e$1@news.cybercity.dk...
> Alt kan diskuteres, men denormalisering kan tit forbedre performance
> drastisk og ofte uden at det gør den store forskel for databasemodellens
> brugbarhed. Det er jo fx de færreste datamodeller der er på 5. Normalform
> (eller højere). Ja faktisk er de færreste datamodeller på 3. Normalform.

Ofte er det jo også afhængigt af hvilken skalerbarhed man ønsker af sin
databasestruktur.

> Jeg forstår ikke dit problem med visning af det enkelte indlæg. Har du
ikke
> indlægets subject liggende i XML træet samt hele beskeden liggend i sin
egen
> tabel?

Jeg har kun beskeden der starter tråden liggende i databasen, resten ligger
i XML og det er for ressourcekrævende at skulle til at finde den enkelte
besked i XML'en ved visning.

--
Jakob Andersen

---

"Jakob Andersen" <jakob@effectus.dk> wrote in message
news:aagosq$dv2$1@news.cybercity.dk...
> "Allan Ebdrup" <ebdrup@ti-fire.dk> wrote in message
> news:aacfto$1l4e$1@news.cybercity.dk...
> > Alt kan diskuteres, men denormalisering kan tit forbedre performance
> > drastisk og ofte uden at det gør den store forskel for databasemodellens
> > brugbarhed. Det er jo fx de færreste datamodeller der er på 5.
Normalform
> > (eller højere). Ja faktisk er de færreste datamodeller på 3. Normalform.
>
> Ofte er det jo også afhængigt af hvilken skalerbarhed man ønsker af sin
> databasestruktur.

Ja, og/eller hvor hurtigt/nemt man laver løsningen, hvor nemt det skal være
at udvidde løsningen i fremtiden, hvor robust den skal være osv.

> > Jeg forstår ikke dit problem med visning af det enkelte indlæg. Har du
> ikke
> > indlægets subject liggende i XML træet samt hele beskeden liggend i sin
> egen
> > tabel?
>
> Jeg har kun beskeden der starter tråden liggende i databasen, resten
ligger
> i XML og det er for ressourcekrævende at skulle til at finde den enkelte
> besked i XML'en ved visning.

Så skal du jo bare gemme data som du ville have gjort uden XML træet og lade
XML træet være et cachet "view" af dine data som du skal vedligeholde. Så
kan du både hente strukturen hurtigt via XML træet, og hente et enkelt
indlæg via de "normale" tabeller. Der bliver redundans i datamodellen men du
får god performance på de udtræk du har nævnt...

MVH
Allan

---

"Allan Ebdrup" <ebdrup@ti-fire.dk> skrev i en meddelelse
news:aah6rg$14k6$1@news.cybercity.dk...
> Så skal du jo bare gemme data som du ville have gjort uden XML træet og
lade
> XML træet være et cachet "view" af dine data som du skal vedligeholde. Så
> kan du både hente strukturen hurtigt via XML træet, og hente et enkelt
> indlæg via de "normale" tabeller. Der bliver redundans i datamodellen men
du
> får god performance på de udtræk du har nævnt...

Ja, det var selvfølgelig en mulighed. Den er nok glippet da jeg nærmest får
det dårligt ved tanken om at lagre alle overskrifter + datoer og forfattere
to steder. Redundansen bliver lidt for voldsom til min kop te

--
Jakob Andersen

---

"Jakob Andersen" <jakob@effectus.dk> wrote in message
news:aaj4i1$od4$1@sunsite.dk...
> "Allan Ebdrup" <ebdrup@ti-fire.dk> skrev i en meddelelse
> news:aah6rg$14k6$1@news.cybercity.dk...
> > Så skal du jo bare gemme data som du ville have gjort uden XML træet og
> lade
> > XML træet være et cachet "view" af dine data som du skal vedligeholde.
Så
> > kan du både hente strukturen hurtigt via XML træet, og hente et enkelt
> > indlæg via de "normale" tabeller. Der bliver redundans i datamodellen
men
> du
> > får god performance på de udtræk du har nævnt...
>
> Ja, det var selvfølgelig en mulighed. Den er nok glippet da jeg nærmest
får
> det dårligt ved tanken om at lagre alle overskrifter + datoer og
forfattere
> to steder. Redundansen bliver lidt for voldsom til min kop te

Hehe, ja det er ikke "pænt".
Det kunne være rigtigt rart hvis databaser havde mulighed for at definere et
clustred index baseret på en træstruktur, defineret ved en selvreferende
tabel.
Jeg har foreslået det til MS og deres XML gutter var interreserede, men det
er 1 år siden og jeg har ikke hørt fra dem. Det er nok ikke højest på deres
prioterings liste at lave bedre understøttelse for hierakiske datastrukture
i en relationel database. Der er jo altid datashaping, med det er ikke
kraftfuldt nok til hierakier af dynamisk størrelse. Så må man jo lave
"hacks" der har egenskaber der er tilpasset den enkelte opgave.

MVH
Allan