Cosa dovrei usare? Una stringa o 15 campi interi?


9

Sto sviluppando un programma di monitoraggio degli studenti in cui devo memorizzare 15 voti d'esame.

Posso memorizzare i segni come una stringa e suddividerli quando necessario, per scopi come eseguire operazioni aritmetiche. Tuttavia, ho bisogno di più prestazioni possibili.

Che è migliore? Un singolo campo stringa o 15 singoli campi int?


"15 voti d'esame" - così come la scelta multipla di un singolo esame o i punteggi di 15 esami?
rfusca,

punteggi di 15 prove
microfono

1
Senza ulteriori informazioni sul tipo di database (tradizionale relazionale con indicizzazione disponibile?) E sui requisiti per l'accesso ai dati e i modelli di utilizzo, è difficile dire quale progetto si dovrebbe usare e come funzionerà.
Cade Roux,

Risposte:


27

Se stai già parlando di divisione e calcolo, non archiviarlo come un array.

Indipendentemente dalla teoria relazionale, dalle tradizionali regole di normalizzazione e dal dogma, è semplicemente un design che ti offre una flessibilità MINIMA.

Trasforma ogni risultato di esame in una riga.

Non sto cercando di anticipare tutto, ma ci sono un numero molto grande di cose che questo design più granulare (e, sì, normalizzato) e solo leggermente più costoso dello spazio facilita di cui potresti avere bisogno o meno ora e potrebbe o potrebbe non essere necessario in futuro:

  • Eliminare il risultato più alto e più basso? Dovrai tagliare il tuo array e ordinarlo.

  • Della media? Dovrai dividerlo e sommarlo

  • Analisi del risultato dell'esame mediante esame tra gli studenti? Dovrai tagliare e ruotare

  • Ordinamento per il conteggio (o istanza GCSE britannica, dove potrebbero essere 7 As e 2B)? Dovrai tagliare e ordinare

Si noti che tutte queste operazioni di taglio e smistamento sono molto economiche in un design indicizzato e normalizzato.


4
Proprio quello che stavo per dire ma l'hai detto meglio! La memorizzazione di valori multipli in una stringa è una delle peggiori scelte di progettazione possibili per qualsiasi database.
HLGEM,

+1 Ottima ulteriore spiegazione dalla mia. Tendo ad essere troppo conciso lol.
rfusca,

12

Per i punteggi, per quanto riguarda le prestazioni, il chiaro vincitore lo sta memorizzando numericamente qualcosa del genere;

create table test_scores
(
  student_id int,
  test_id int,
  score int
);

È facile da interrogare, facile da aggiornare e aggiungere, e super facile e veloce per eseguire aggregati. Data la scelta di "memorizzare queste informazioni come una stringa che devo dividere" o "memorizzare in una colonna" ... il vincitore sarà quasi sempre "memorizzare in una colonna" per la maggior parte dei casi d'uso in un RDBMS.


Se è sempre lo stesso set di 15 esami, potrebbe essere che la loro memorizzazione denormalizzata (15 colonne) sia più veloce da elaborare. Una domanda, hai proposto di proposito un tipo di dati intero?
Edward Dortland,

Inoltre, per ogni 15 esami di 1 studente ora stai memorizzando 15 volte un ID studente e un ID prova extra.
Edward Dortland,


6
@EdwardDortland saranno sempre 15 finché non lo sarà.
da

1
@EdwardDortland: i calcoli vanno bene. Ora, puoi farli per gli indici di cui potresti aver bisogno?
ypercubeᵀᴹ

1

purché si usi tiny int (da 0 a 255) usando un carattere (15) o 15 tinyint è lo stesso (dimensione saggia). Quindi, dal punto di vista delle prestazioni, scegli i 15 minuscoli poiché risparmi sull'estrazione e sulla gestione delle stringhe.

AGGIORNARE

se i segni sono a due cifre, avrai bisogno di CHAR (30) e che è due volte la dimensione di 15 volte un minuscolo.


9
Dato questo design estremamente semplice, se c'è un'istituzione su questo pianeta che ha abbastanza studenti che sostengono 15 esami (con voti) per causare problemi di prestazioni in un moderno RDBMS, piangerò per dormire stanotte.
Philᵀᴹ

1
Se i segni sono a doppia cifra? Ma minuscolo int copre i punteggi da 0 a 255 o da -127 a 127 a seconda di come preferisci contare. Quindi, dal momento che i punteggi raramente diventano negativi, questo dà 250+ punti per un esame e la maggior parte degli esami viene valutata su una scala 0-100%. Penso che tinyint sia assolutamente utile qui.
jcolebrand

Sì, siamo d'accordo, stavo semplicemente affermando che con i segni a due cifre come impressi sui segni a una cifra diventa ancora peggio memorizzarlo come carattere. Da allora avresti bisogno di char (30) invece di char (15). Anche se a doppia cifra o meno, 15 minuscoli saranno sempre solo 15 byte.
Edward Dortland,

-1 perché questa risposta raccomanda di progettare i campi per riga che sono di gran lunga inferiori alla memorizzazione di ogni risultato dell'esame nella propria riga come proposto dagli altri post
miracle173
Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.