Der er flere spørgsmål/problemer her, så jeg vil prøve at besvare hvert enkelt.
Alle turneringsinteraktioner bør være realtid/afspejles for mange brugere.
For små til mellemstore trafik på dit websted er dette muligvis ikke et problem. For tung trafik vil dette hurtigt begynde at blive et stort problem.
Overvej som et eksempel, hvor ofte du ønsker at polle databasen med dine AJAX-opkald. Hvert sekund? Så hvis du har 100 personer med en åben side, har du 100 databasekald hvert sekund? Du vil opdage, at det hurtigt vil dræbe din database.
Selvom dette er lidt uden for emnet, vil jeg stærkt anbefale at undersøge, hvordan man cache turneringsresultater på forhånd. Du kan cache statistikken osv. og enten lade dem udløbe eller udløbe dem proaktivt, men brug helt sikkert noget tid på at undersøge det.
Statistik/resultater i realtid
Husk, at joinforbindelser tager tid i relationelle databaser. Hvis du normaliserer din turneringsstruktur kraftigt, kan det være smertefuldt at få statistik. Den sværeste del af systemet at gøre effektivt vil være aggregater og statistik fra hver turnering.
Når du designer din database/tabeller/visninger/lagrede procedurer, skal du huske på slutmålet - at få statistik hurtigt. Dette kan betyde ikke normalisering af dataene for meget (for at undgå for mange joins). Det kan også betyde, at du er meget opmærksom på dine datatyper - for eksempel ved at bruge bits/shorts/etc. i stedet for heltal.
Sådan modelleres de forskellige turneringstyper
Jeg er ikke bekendt med turneringsmodeller, men jeg har specifikke råd om, hvordan man modellerer. =)
Nogle spørgsmål, du bør stille dig selv:
-
Har alle turneringer fælles felter? Med andre ord, til en round robin-turnering gemmer vi 10 felter. Til en enkelt elimineringsturnering gemmer vi 11 felter. Hvis de deler de samme 10 felter, så vil jeg anbefale at lægge alle turneringstyper i én tabel og derefter bruge et turneringstype-felt til at bestemme turneringstypen for din ansøgning.
-
Har alle turneringer ikke fælles felter? Lav dem til separate borde - et pr. turneringstype. Du laver måske én tabel til delte data, men har så forskellige tabeller til specifikke oplysninger.
-
Vil turneringsfelter vokse fra hinanden over tid ? Med tiden vil du gerne tilføje felter til turneringstyper. Hvis du forudser, at turneringerne vil blive meget unikke og meget specifikke over tid, så gør dem adskilt. Ellers ender du med masser af felter, der har tonsvis af NULL-værdier i dem.
-
Har du overvejet en NoSQL-løsning ? Det fine ved en NoSQL-butik er, at den denormaliserer dataene, så du ikke har joins. Du kan også have heterogene (forskellige typer data) i den samme "tabel" eller container. Bare noget at overveje, fordi det kan gøre dit liv betydeligt lettere. Tjek MongoDB som et eksempel.