Suggerimenti per la progettazione di database in un'applicazione Web [chiuso]

Question

Qualcuno ha qualche suggerimento/consiglio sulla progettazione del database per un'applicazione web?Il tipo di cose che possono farmi risparmiare molto tempo/fatica in futuro quando/se l'applicazione su cui sto lavorando decolla e inizia ad essere molto utilizzata.

Per essere un po' più specifici, l'applicazione è un gioco di strategia (basato su browser, solo testo) che coinvolgerà principalmente i giocatori che impartiscono "ordini" che verranno archiviati nel database ed elaborati successivamente, dove verranno archiviati anche i risultati (la cronologia di "ordini" e i risultati corrispondenti probabilmente diventeranno piuttosto grandi).

Modificato per aggiungere ulteriori dettagli (come richiesto):

piattaforma:Django

motore di database:Stavo pensando di usare MySQL (a meno che non ci sia un grande vantaggio nell'usarne un altro)

lo schema:tutto quello che ho adesso sono alcuni modelli di Django, e questi sono troppi dettagli per pubblicarli qui.E se inizio a pubblicare schemi, questo diventa troppo specifico e stavo cercando suggerimenti generali.Ad esempio, considera che emetto "ordini" che verranno successivamente elaborati e restituisco un risultato che devo archiviare per visualizzare una sorta di "storia".In questo caso è meglio avere una tabella separata per la "storia" o solo una che aggreghi sia gli "ordini" che il risultato?Immagino che potrei memorizzare nella cache la tabella "cronologia", ma ciò richiederebbe più spazio nel database e anche più operazioni di database perché dovrei creare costantemente nuove righe invece di modificarle semplicemente nella tabella aggregata.

Answer 1

Probabilmente hai toccato un problema molto più ampio relativo alla progettazione per un'elevata scalabilità e prestazioni in generale.

Essenzialmente, per la progettazione del tuo database seguirei buone pratiche come aggiungere chiavi esterne e indici ai dati che prevedi di essere utilizzati frequentemente, normalizzare i tuoi dati suddividendoli in tabelle più piccole e identificare quali dati devono essere letti frequentemente e quali devono essere letti scritto frequentemente e ottimizzare.

Molto più importante della progettazione del database per applicazioni Web ad alte prestazioni, è l'uso efficace della memorizzazione nella cache sia a livello di client tramite la memorizzazione nella cache di pagine HTML che a livello di server tramite dati memorizzati nella cache o fornendo file statici al posto di file dinamici.

Il bello della memorizzazione nella cache è che può essere aggiunta quando necessario, in modo che quando la tua applicazione decolla tu possa evolversi di conseguenza.

Per quanto riguarda i dati storici, questa è un'ottima cosa da memorizzare nella cache poiché non ti aspetti che cambino frequentemente.Se desideri produrre report regolari e abbastanza approfonditi dai tuoi dati, allora è buona pratica inserire questi dati in un altro database in modo da non arrestare la tua applicazione web mentre è in esecuzione.

Naturalmente questo tipo di ottimizzazione non è realmente necessaria a meno che non si pensi che la propria applicazione lo garantisca.

Answer 2

Normalizzazione del database, e riflettere bene sugli indici, sono due cose che non puoi assolutamente perderti.Soprattutto se consideri un gioco, in cui i SELECT si verificano molto più frequentemente degli AGGIORNAMENTI.

A lungo termine, dovresti anche dare un'occhiata memcached, poiché le query del database possono rappresentare un collo di bottiglia ogni volta che si hanno più utenti.

Answer 3

Perché non pubblichi lo schema che hai adesso?È una domanda troppo ampia a cui rispondere in modo utile senza alcuni dettagli su quale piattaforma e database utilizzerai e sulla struttura della tabella che stai proponendo...

Answer 4

Dovresti denormalizzare le tue tabelle se ti ritrovi a unire più di 6 tabelle in un'unica query per recuperare i dati per una pagina Web di tipo report che verrà utilizzata spesso.Inoltre, se utilizzi librerie ORM come Hibernate o ActiveRecord, assicurati di dedicare un po' di tempo alle mappature predefinite che generano e all'SQL che finisce per generare.Tendono ad essere molto loquaci con il database quando avresti potuto ottenere gli stessi risultati con un solo viaggio di andata e ritorno al database.