Semplice design / layout della tabella del database

Question

Mi sto solo chiedendo, come esempio ipotetico , quale sarebbe il modo migliore per impaginare una tabella per il seguente scenario:

Supponiamo che stia scrivendo un'app per il monitoraggio di partecipazione degli studenti . All'inizio di ogni anno, voglio aggiungere tutti gli studenti (lo farò manualmente - ora, se un ID studente deve essere assegnato a ciascuno qui? Chiamiamo quella tabella Studenti ). Ora, ogni giorno, mostrerò tutti gli studenti nella tabella Studenti e consentirò all'utente di scegliere la frequenza.

Quindi, come dovrei posare il mio tavolo? (Se non capisci cosa intendo, intendo quali dati devono essere immessi in ogni colonna, riga ...) Ad esempio, magari avere una tabella Studenti con ID Studente e per ogni studente creare ogni giorno una nuova riga nella Tabella delle presenze con la colonna 1: ID studente, colonna 2: data, colonna 3: stato (presente / assente). Tuttavia, ciò non sembra essere molto efficiente. Cosa ne pensi?

AGGIORNAMENTO: Da tutte queste prime risposte, sembra che uno studente si trovi in ??ogni riga della tabella delle presenze degli studenti (dove è designato come presente / assente), ma cosa succede se io dovevano includere più di un ID studente per riga, diciamo per tutti gli studenti assenti un giorno? Sarebbe meglio o peggio (probabilmente è ambiguo)? In realtà, sto iniziando a pensare che l'efficienza sarebbe diminuita perché le uniche azioni che questa mossa aiuta anche possono essere già facilmente realizzate. Hmm ...

Answer 1

STUDENTI tabella

• STUDENT_ID , pk
• FIRST_NAME
• LAST_NAME

STUDENT_ATTENDANCE tabella

• STUDENT_ID , pk, fk
• ABSENT_DATE , pk

Non è necessaria una colonna IS_ABSENT - avere una data indica che sia lo studente assente, sia a quale data. Probabilmente ci saranno meno giorni di assenza rispetto a quelli frequentati, quindi memorizza solo le date di assenza.

Rendere la chiave primaria composta da due colonne garantisce che non si avranno duplicati.

  

cosa succede se dovessi includere più di un ID studente per riga, diciamo per tutti gli studenti assenti un giorno? Sarebbe meglio o peggio

Quindi stai memorizzando gli studenti_id aggiuntivi come un elenco separato da virgole in una singola colonna o colonne aggiuntive per ogni studente_id aggiuntivo. Le colonne aggiuntive per ogni student_id non funzionerebbero mai: aggiungeresti una colonna per ogni nuovo studente, ogni anno. Concatenare un elenco di student_ids è più realistico, ma sarà una seccatura estrarre i dettagli se si desidera creare report su uno specifico studente o gruppo di studenti. A causa dei limiti di carattere, corre il rischio di non essere in grado di memorizzare ogni studente_id che potrebbe essere assente con una singola colonna.

Consiglio di utilizzare la tabella STUDENT_ATTENDANCE che ho suggerito.

Answer 2

Il punto chiave sulla progettazione del database è fornire un modello con integrità. Quindi nel tuo esempio non vorrai registrare le assenze degli studenti per le date che cadono nei fine settimana, nei giorni festivi o nei giorni di inserimento. Quindi hai anche bisogno di una tabella CALENDARIO. STUDENT_ABSENCE sarebbe una tabella di intersezione tra STUDENT e CALENDAR. Cioè, avrebbe chiavi esterne sia per un ID nella tabella STUDENT sia per un DAY nel CALENDARIO.

Questo può sembrare un eccesso di ingegneria, ma praticamente tutto ciò che accade in una scuola implica la pianificazione, quindi un CALENDARIO è essenziale. Potresti anche usarlo il più possibile, per costruire il miglior modello che puoi.

Inoltre, considera quali altri attributi sono necessari alla tabella STUDENT_ABSENCE. Al di fuori della mia testa potresti sapere cosa registrare se l'assenza è stata comunicata in anticipo (ad esempio per una vacanza in famiglia durante il periodo di tempo), se l'assenza è stata approvata, se l'assenza è dovuta a malattia.

Answer 3

Avrei un tavolo MissedClasses con StudentID come chiave esterna, la data, il corso e forse il periodo e forse un'altra colonna per scusarmi o meno. Inserire una voce se non hanno partecipato.

Il mio ragionamento: spero che la maggior parte parteciperà alla maggior parte delle lezioni, quindi devi solo tenere traccia dei fallimenti.

Answer 4

Se combini più valori in un elenco di valori e li memorizzi in una singola cella, la tabella non è più nella prima forma normale, come originariamente definito da Codd. È possibile conformarsi al primo modulo normale come ridefinito da Data memorizzando una tabella all'interno di una tabella. La maggior parte dei neofiti non lo fa. Di solito schiacciano l'elenco di valori in una stringa di caratteri separata da virgola e memorizzano l'intero elenco come se fosse un singolo valore atomico.

Ciò che trovano in seguito è che non possono più sfruttare il potere degli operatori relazionali, in particolare il join, al fine di esprimere operazioni complesse in modo semplice. Questo di solito costa al neofita più di "inefficienza". avrebbe. Anche se inserisci una tabella all'interno di una tabella, scoprirai che fare cose di routine con i dati è molto più difficile di quanto non debba essere.

La maggior parte dei buoni suggerimenti che hai ricevuto riguarda la decomposizione delle tabelle per ottenere uno schema normalizzato. Questo è di solito il miglior piano da seguire, fino a quando non imparerai in un secondo momento quando infrangere le regole di normalizzazione e quando seguirle.

Questo non è scritto per un tipico bambino di 12 anni. Non sembri un tipico dodicenne. Quindi sto cercando di darti un punto sui fondamenti della buona progettazione del database, invece di farti imparare la cattiva progettazione del database al liceo, e quindi devo disimpararlo e ricominciare da capo più tardi.

Answer 5

Avrei una tabella studenti con ID studente e informazioni specifiche per ogni studente come nome, voto, ecc. Quindi avrei una tabella studente_attendenza con ID studente, data, stato (presente / assente).

Anche se questo raccoglie molti dati, in realtà non sono molti dati e ti consente di eseguire facilmente diversi tipi di rapporti di presenza.

Non vorresti mettere più di un ID studente in una singola riga perché anche se avresti meno righe, avresti la stessa quantità di dati e interrogare la tabella / i rapporti sarebbe imbarazzante.