Ci sono diverse domande/problemi qui, quindi cercherò di affrontarli.
Tutte le interazioni del torneo dovrebbero essere in tempo reale/riflettere a molti utenti.
Per il traffico medio-basso sul tuo sito web, questo potrebbe non essere un problema. Per il traffico più intenso, questo comincerà rapidamente a essere un grosso problema.
Considera come esempio la frequenza con cui desideri eseguire il polling del database con le tue chiamate AJAX. Ogni secondo? Quindi, se hai 100 persone con una pagina aperta, hai 100 chiamate al database ogni secondo? Scoprirai che ucciderà rapidamente il tuo database.
Anche se questo è leggermente fuori tema, consiglio vivamente di indagare su come memorizzare nella cache i risultati del torneo in anticipo. Puoi memorizzare nella cache le statistiche, ecc. e lasciarle scadere o farle scadere in modo proattivo, ma dedicare sicuramente un po' di tempo alla ricerca.
Statistiche/risultati in tempo reale
Tieni presente che i join richiedono tempo nei database relazionali. Se normalizzi pesantemente la struttura del tuo torneo, ottenere le statistiche potrebbe essere doloroso. La parte più difficile da rendere efficiente del sistema saranno gli aggregati e le statistiche di ogni torneo.
Quando stai progettando il tuo database/tabelle/viste/procedure archiviate, tieni presente l'obiettivo finale:ottenere rapidamente le statistiche. Questo potrebbe significare non normalizzare troppo i dati (per evitare troppi join). Potrebbe anche significare prestare molta attenzione ai tuoi tipi di dati, ad esempio usando bit/cortocircuiti/ecc. invece di numeri interi.
Come modellare i diversi tipi di torneo
Non ho familiarità con i modelli da torneo, ma ho consigli specifici su come modellare. =)
Alcune domande che dovresti porti:
-
Tutti i tornei hanno campi comuni? In altre parole, per un torneo all'italiana memorizziamo 10 campi. Per un torneo a eliminazione diretta memorizziamo 11 campi. Se condividono gli stessi 10 campi, consiglierei di mettere tutti i tipi di torneo in una tabella e quindi utilizzare un campo tipo_torneo per determinare il tipo di torneo per la tua applicazione.
-
Tutti i tornei non hanno campi comuni? Rendili tavoli separati, uno per tipo di torneo. Potresti creare una tabella per i dati condivisi, ma poi avere tabelle diverse per informazioni specifiche.
-
I campi dei tornei si sfalderanno nel tempo ? Nel tempo vorrai aggiungere campi ai tipi di torneo. Se prevedi che i tornei diventeranno unici e molto specifici nel tempo, separali. Altrimenti ti ritroverai con molti campi che contengono tonnellate di valori NULL.
-
Hai preso in considerazione una soluzione NoSQL ? La cosa bella di un negozio NoSQL è che denormalizza i dati in modo da non avere join. Inoltre puoi avere eterogenei (diversi tipi di dati) nella stessa "tabella" o contenitore. Solo qualcosa da considerare perché potrebbe semplificarti notevolmente la vita. Dai un'occhiata a MongoDB come esempio.
