Progettazione del database per il sistema di presenze scolastiche

Question

Sto lavorando a un progetto per una scuola in cui un modulo specifico si occupa del sistema di presenze. Sto usando lo stack LAMP (PHP 5.2+ MYSQL 5+) per lo sviluppo. Ora la forza della scuola è intorno al 1500 e il numero totale di giorni lavorativi all'anno è di circa 250. Inoltre, devo conservare i documenti per 5 anni prima che possa essere cancellato.

La struttura della tabella è

studentId varchar(12) 
date date 
fn varchar(1) *forenoon* 
af varchar(1) *afternoon* 

Se ho semplicemente utilizzare un unico tavolo, che significa 1.875.000 record per un periodo di 5 anni. Ora invece di un database così gigantesco, ho pensato di creare un tavolo per ogni classe (non una sezione). Quindi considerando che ci sono 12 classi, avrò 12 tabelle, il che significa una media di 1,55.000 record per tabella che è gestibile.

È questo il modo giusto per farlo? O ci sono modi migliori?

Answer 1

Quello che state facendo è chiamato ottimizzazione prematura. Questo è un errore comune.

È meglio ottenere la struttura del database più vicina alla realtà e in futuro se diventa necessario ottimizzare o migliorare la velocità, è sempre possibile farlo.

Per esperienza e guardando il tuo esempio, la soluzione a tavolo singolo sembra soddisfacente.

Answer 2

Purché le colonne della tabella siano state indicizzate correttamente, non ci dovrebbero essere grossi problemi con la prima tabella.

Non sarei d'accordo con l'idea di dividerlo nelle 12 classi, perché non si ha alcuna garanzia che quello sia il modo in cui rimarrà (classi aggiunte, classi si fondono, ecc.).

rendano confusa la normalizzazione dei database per un beneficio percepito di efficienza è qualcosa che si dovrebbe guardare solo per circostanze estreme (se mai)

Answer 3

Un paio di punti.

• 2 milioni di record è non un grande tavolo.
• con una tabella separata per classe è sicuramente non normalizzato.

In realtà non hai fornito abbastanza informazioni sui collegamenti ad altre tabelle e cos'altro, se possibile, questa tabella verrà memorizzata. Ma dovresti iniziare con 3NF per tutte le tabelle e modificarlo solo se trovi problemi di prestazioni.

Answer 4

Suggerirei che non è necessario suddividere questo tavolo. Se si creano indici appropriati per qualsiasi domanda selettiva che potrebbe essere necessario eseguire, il sistema dovrebbe essere in grado di trovare le righe richieste molto rapidamente. Anche per le query analitiche che coinvolgono tutte le righe, 2 milioni di tali record dovrebbero richiedere solo un secondo o due per la scansione, che immagino non presenterebbe un grosso problema.

MySQL ora supporta anche il partizionamento dei dati come funzionalità opzionale. Il partizionamento è simile alla tua proposta di dividere il tavolo, ma è fatto a livello fisico, quindi non è visibile agli utenti o agli sviluppatori che utilizzano lo schema. Questo può essere un approccio utile se si scopre che un'implementazione a tabella singola è ancora troppo lenta. This document fornisce una panoramica del partizionamento in MySQL 5.4.

Answer 5

Checksum,

ho eco Michiel opinin che questo è l'ottimizzazione prematura.

Ciò che in sostanza si può fare in seguito per migliorare le prestazioni è utilizzare le funzionalità di archiviazione e partizionamento del database in modo che le letture del database siano efficienti. Posso anche creare l'indice su questa tabella. Comunque non credo che 1 milione di dischi sia enorme. I database oggi sono in grado di gestire numeri così grandi. Inoltre si incontrano i problemi di prestazioni 3 anni di modulo ora solo

Quindi, andare avanti scrivere il codice piuttosto che pensare a cosa andare storto!