Risposta iniziale

Alcuni aspetti preliminari:

• In pratica trovo che sia utile inserire i campi data per i tempi creati / modificati; rende la vita molto più facile durante il debug dei problemi dei dati. Praticamente qualsiasi tavolo che non sia una tabella di ricerca potrebbe trarne vantaggio. Se una tabella è in scrittura una volta, considera di rinunciare alla colonna del tempo modificata.

• Assicurati di non memorizzare le password in testo semplice. È oltre lo scopo di questa domanda, ma ho pensato di prendermi il tempo per dirlo.

Detto questo, penso che ti preoccupi prematuramente di cose come la scalabilità finché non avrai effettivamente alcuni dati per il backup dei tuoi problemi. Detto questo, ho un semplice suggerimento.

If a subject is of 40 lectures then it requires almost 80*40=3200 records for recording attendance of a single subject per class; so what about 6 more subjects in each semester.

È vero che stai aggiungendo molti record, ma quei record fino ad ora sembrano essere ... 10 byte ciascuno? Non ho intenzione di cercare le dimensioni dei tipi di dati, ma non stai distruggendo il banco con 10 righe di byte. Ho il sospetto che mentre gli utenti vogliono sempre avere la presenza disponibile, è probabile che concordare un criterio di conservazione possa aiutarti a limitare la crescita e consentire di ridurre i record di presenze degli anni passati.

Tuttavia, hai spazio per ottimizzare. Anziché registrare una presenza per ogni Student in una relazione uno a uno, ti suggerisco di registrare la presenza selezionando il minore tra "partecipato" o "mancato" e registrando solo quello. Ad esempio, se ritieni che la maggior parte degli studenti segua la lezione, selezionerai "mancato", il che significa che la tabella Attendance avrà solo righe per Student s che hanno perso la lezione. Se un Student ha una riga nella tabella Attendance ha perso la lezione, altrimenti era presente. Ovviamente in questo caso, Attendance dovrebbe essere rinominato in qualcosa come Absence o qualcosa del genere.

Dedica più tempo a considerare cosa potresti fare quando i tuoi stakeholder vogliono aggiungere più dati allo schema. Gli esempi includono l'aggiunta di categorie o raggruppamenti, alias o nomi secondari o e-mail secondarie.

Riguardo alla generazione di tabelle dinamiche

Which tables should be kept as they are [i.e should be created only once] and which tables should be created dynamically and at what interval? [i.e year-wise/ semester-wise/ any other suggestions]

Questa è una preoccupazione prematura poiché non sai ancora quali sono i tuoi problemi di prestazioni. Sarei propenso a cercare tavoli con prestazioni scadenti dopo il rilascio e a creare un processo di archiviazione in base alle tue esigenze.

Non raccomando di creare dinamicamente tabelle in quanto dovresti apportare modifiche allo schema del database sull'host live che ha un impatto sull'applicazione, che potrebbe potenzialmente far cadere l'applicazione se commetti un errore di battitura. Per rispondere alla tua domanda, ti consiglio di archiviare i dati a livello di riga.

Se hai bisogno che i vecchi dati siano altamente disponibili ma a cui si accede raramente, puoi farlo emergere usando un modulo separato dell'applicazione, con il suo database separato. Questo database può essere popolato da un processo esterno che sposta le righe (durante una finestra di manutenzione) dal modulo attivo / attivo al modulo di archivio.

Se non è necessario che sia così disponibile, è possibile esportare le righe dal database attivo (durante una finestra di manutenzione) in un archivio compresso correttamente sottoposto a backup e può essere rivisto su richiesta utilizzando gli strumenti di sviluppo.

Il vantaggio di questo approccio è che le operazioni di riga non elimineranno il sito; il caso peggiore è che alcuni dati mancano per un po 'o le prestazioni sono degradate.

Come sviluppatore principale spetta a te determinare quali sono i bisogni e agire di conseguenza. Ancora una volta, ti consiglio di sospendere questo tipo di lavoro finché non avrai un problema concreto.