C'è un vantaggio sull'impostazione di campi tinyint quando so che il valore non supererà 255?

Question

Dovrei scegliere il tipo di dati più piccolo possibile, o se sto memorizzando il valore 1 per esempio, non importa quale sia il tipo di dati col e il valore occuperà la stessa dimensione di memoria?

La domanda è anche, perché dovrò sempre convertirla e giocare nell'applicazione.

---

Aggiorna

Penso che varchar (1) e varchar (50) abbiano le stesse dimensioni della memoria se il valore è " a " ;, ho pensato che fosse lo stesso con int e tinyint, secondo le risposte capisco che non lo è, vero?

Answer 1

Scegli sempre il tipo di dati più piccolo possibile. SQL non può indovinare quale vuoi sia il valore massimo, ma può ottimizzare l'archiviazione e le prestazioni una volta che gli dici il tipo di dati.

---

Per rispondere al tuo aggiornamento:

varchar occupa solo lo spazio che usi e quindi hai ragione quando dici che il carattere " a " occuperà 1 byte (in codifica latina), indipendentemente dalla dimensione del campo varchar che scegli. Questo non è il caso di nessun altro tipo di campo in SQL.

Tuttavia, sacrificerai l'efficienza per lo spazio se trasformi tutto in un campo varchar. Se tutto è un campo di dimensioni fisse, SQL può eseguire una semplice moltiplicazione a tempo costante per trovare il valore (come un array). Se hai campi varchar lì dentro, l'unico modo per scoprire dove sono archiviati i tuoi dati per passare attraverso tutti i campi precedenti (come un elenco collegato).

Se stai iniziando a SQL, ti consiglio di stare lontano dai campi varchar a meno che non ti aspetti di avere campi che a volte hanno quantità molto piccole di testo e talvolta quantità molto grandi di testo (come i post sul blog). Ci vuole esperienza per sapere quando utilizzare i campi a lunghezza variabile con il miglior effetto e anche io non lo so la maggior parte delle volte.

Answer 2

È una considerazione delle prestazioni particolare per il design del tuo sistema. In generale, più dati è possibile inserire in una pagina di dati SQL Server, migliori sono le prestazioni.

Una pagina in SQL Server è 8k. L'uso di minuscoli ints anziché ints ti consentirà di inserire più dati in una singola pagina ma devi considerare se ne vale la pena. Se stai per ricevere migliaia di colpi al minuto, allora sì. Se questo è un progetto hobby o qualcosa che solo poche decine di utenti vedranno mai, allora non importa.

Answer 3

Il vantaggio è presente ma potrebbe non essere significativo a meno che non si disponga di molte righe e si esegua una perdita di operazioni. Ci saranno miglioramenti delle prestazioni e spazio di archiviazione ridotto.

Answer 4

Tradizionalmente ogni bit salvato sulla dimensione della pagina significherebbe un po 'di miglioramento della velocità: le righe più strette significano più righe per pagina, il che significa meno memoria consumata e meno richieste di I / O, con conseguente migliore velocità. Tuttavia, con SQL Server 2008 Compressione della pagina le cose iniziano a diventare confuse. L'algoritmo di compressione può comprimere 4 byte con valori inferiori a 255 su anche meno di un byte.

Gli algoritmi di

?? Compressione di riga memorizzeranno un int di 4 byte in un byte singolo per valori inferiori a 127 (int è firmato), 2 byte per valori inferiori a 32768 e così via e così via.

Tuttavia, dato che le belle funzioni di compressione sono disponibili solo sui server Enterprise Edition, ha senso mantenere l'abitudine di utilizzare il tipo di dati più piccolo possibile.