Forum database struktur

Tags:    databaser

Hey folkens,

Jeg kunne godt tænke mig at høre jeres mening om et konkret problem jeg sidder med lige nu. Jeg skal genopbygge eForum systemet til den nye Udvikleren.dk. Den gamle version lavede jeg jo for flere år siden, og jeg synes faktisk at den har kørt ganske udmærket. Jeg overvejer dog kraftigt om det ikke er på tide at ændre drastigt på database strukturen, men jeg er dog alvorligt i tvivl om hvor vidt det er en god ide eller ej. Lad mig forklare hvordan det fungerer på nuværende tidspunkt.

Hvert forum har 3 tabeller - en der indeholder selve indlæggene (dvs. forfatter, tekst osv.), en der indeholder alle trådene (dvs. ting som emne, start dato, evt. antal UP osv.), samt en der holder styr på det man på godt gammeldags dansk kan kalde "read status", altså hvem der har læst hvilke tråde og hvor meget af dem. Den sidste er meget vigtig, da den gør at der altid bliver holdt styr på hvilke tråde man har læst, hvor mange indlæg der var da man læste den (så der kan tjekkes om der er kommet nye indlæg siden sidst) og den slags. Det fungerer ved at hver udvikler (det gælder kun for folk der er logget ind) får en række i denne tabel for hver tråd der læses. Kan I selv gætte hvor hurtigt det kan løbe op? :). Lige nu er PHP foraet's status tabel fx på over 22 mb, på trods af at den KUN indeholder tal. Næsten en halv million rækker er det blevet til, og det er jo helt vildt meget. Jeg har lavet denne opdeling fordi jeg i sin tid mente at det performancemæssigt var det bedste, og det tror jeg sådan set stadig på.

Men hvad er problemet så? Jo, det er belastende med 3 tabeller pr. forum! Lige nu er der omkring 25 forums på sitet, og det giver altså 75 tabeller, hvilket ikke ligefrem gør det overskueligt at kigge i databasen :). Derudover det også besværligt at oprette nye forums osv osv. Hvis jeg samtidig skulle implementere en form for arkiverings funktion, så vi ikke altid skal glo på alle de gamle tråde, ja så skal der enten 75 tabeller ekstra til, eller også skal jeg til at lave "tricks" :). Og en sidste ulempe er søgning, og en hver anden aktivitet der involverer at skulle lede alle forums igennem for et eller andet.

Alternativet er at lave det om så der kun er 3 tabeller, som deles af alle forums, men med den volumen jeg netop har nævnt på blot ét af foraerne her på sitet, virker det, for mig i hvert fald, som en lidt vanvittig tanke at skulle slå det sammen. Fx indeholder PHP foraets message tabel knap 15.000 records, og fylder knap 12 mb. Det kan ret hurtigt løbe op hvis alle deler samme tabel. Men måske er det ikke det store problem? Jeg forestiller mig at man kunne implementere noget arkivering af en art, men jeg ved det ikke helt. Hvad siger I? Jeres mening omkring emnet er meget velkommen! :)

--
Mvh.

Kasper (TSW)
Webmaster



2 svar postet i denne tråd vises herunder
1 indlæg har modtaget i alt 4 karma
Sorter efter stemmer Sorter efter dato
En mulighed var at lave følgende (navnene er valgt for at være selvforklarende, det er langt fra sikkert, at det er de mest hensigtsmæssige):

En tabel indeholdende en record for de forskellige fora og underfora (C# skulle fx være child til .NET) - her kan du ligge nogle generelle statistikker (antal tråde etc.). Eks:
- id
- navn
- forumAbove
- statThreads
- stat[...]


En anden tabel indeholder en tråds master (eller hvad man vælger at kalde den - altså det oprindelige spørgsmål)
- id
- forumId (relaterer selvfølgelig til id'et i overstående tabel)
- overskrift
- indhold
- threadAuthor
- antalPoint
- statAnswers
- stat[...]

En tredje tabel kunne så indeholde alle svarerne (denne kunne så joines med overstående i visninger, søgninger etc.):
- id
- answerToThreadId (relaterer selvfølgelig til id'et i overstående tabel)
- indhold
- answerAuthor
- statQuotesToThisAnswer
- stat[...]

Den sidste, store og grumme tabel vil så selvfølgelig være:
- userId
- threadId
- lastAnswerId || numberAnswersInThreadLastVisit

Hvordan det vil spinde rent performancemæssigt sammenlignet med det nuværende, ved jeg ikke umiddelbart. Jeg kan ikke helt gennemskue hvad der vil være bedst - om det er at lave statistikfelterne, så du sparer noget databasebelastning - det betyder selvfølgelig også, at der er mere data, der skal opbevares.

Som sagt er overstående blot et hurtigt idéudkast, der forhåbentlig kan give lidt inspiration :-)

Godnat! :-)

mikl-dk



Tak :P

--
Mvh.

Kasper (TSW)
Webmaster



t