Det finns flera frågor/problem här, så jag ska försöka ta itu med var och en.
Alla turneringsinteraktioner bör vara realtid/reflekteras för många användare.
För liten till medelstor trafik på din webbplats kanske detta inte är ett problem. För tyngre trafik kommer detta snabbt att börja bli en stor fråga.
Betrakta som ett exempel hur ofta du vill polla databasen med dina AJAX-anrop. Varje sekund? Så om du har 100 personer med en sida öppen, har du 100 databasanrop varje sekund? Du kommer att upptäcka att det snabbt kommer att döda din databas.
Även om detta är lite utanför ämnet, skulle jag starkt rekommendera att undersöka hur man cachelagrar turneringsresultat i förväg. Du kan cachelagra statistiken etc. och antingen låta dem upphöra att gälla eller upphöra att gälla proaktivt, men definitivt spendera lite tid på att undersöka det.
Statistik/resultat i realtid
Tänk på att anslutningar tar tid i relationsdatabaser. Om du normaliserar din turneringsstruktur kraftigt kan det vara smärtsamt att få statistik. Den svåraste delen av systemet att effektivisera kommer att vara aggregaten och statistiken från varje turnering.
När du designar din databas/tabeller/vyer/lagrade procedurer, tänk på slutmålet - få statistik snabbt. Detta kan betyda inte normalisera data för mycket (för att undvika för många kopplingar). Det kan också innebära att du är mycket uppmärksam på dina datatyper - till exempel genom att använda bitar/shorts/etc. istället för heltal.
Hur man modellerar de olika turneringstyperna
Jag är inte bekant med turneringsmodeller, men jag har specifika råd om hur man modellerar. =)
Några frågor du bör ställa dig själv:
-
Har alla turneringar gemensamma fält? Med andra ord, för en round robin-turnering lagrar vi 10 fält. För en enda elimineringsturnering lagrar vi 11 fält. Om de delar samma 10 fält, skulle jag rekommendera att lägga alla turneringstyper i en tabell och sedan använda ett fält för tournament_type för att bestämma vilken typ av turnering du vill ha.
-
Har inte alla turneringar gemensamma fält? Gör dem separata bord - ett per turneringstyp. Du kan skapa en tabell för delad data, men sedan ha olika tabeller för specifik information.
-
Kommer turneringsfält att växa isär med tiden ? Med tiden kommer du att vilja lägga till fält till turneringstyper. Om du förutspår att turneringarna kommer att bli väldigt unika och mycket specifika med tiden, separera dem. Annars slutar du med massor av fält som har massor av NULL-värden i dem.
-
Har du funderat på en NoSQL-lösning ? Det fina med en NoSQL-butik är att den denormaliserar data så att du inte har joins. Du kan också ha heterogena (olika typer av data) i samma "tabell" eller behållare. Bara något att tänka på eftersom det kan göra ditt liv betydligt enklare. Kolla in MongoDB som ett exempel.