Quando utilizzare TINYINT su INT?

In generale, utilizzo sempre Ints. So che in teoria questa non è la migliore pratica, dal momento che è necessario utilizzare il tipo di dati più piccolo che sarà garantito per archiviare i dati.

Ad esempio, è meglio usare tinyintquando si sa che gli unici dati che verranno archiviati sono 1, 0 o null (con una probabilità molto piccola di estenderli a 2 o 3 in seguito).

Tuttavia, l'unica ragione che conosco per fare questo è per scopi di archiviazione - utilizzando 1 byte su una riga anziché 4 byte.

Quali sono gli impatti dell'utilizzo tinyint(o smallintpersino bigint) solo intoltre a risparmiare spazio sul disco rigido?

Lo spazio su disco è economico ... non è questo il punto!

Smetti di pensare in termini di spazio di archiviazione, pensa invece al pool di buffer e alla larghezza di banda di archiviazione . All'estremo, cache della CPU e larghezza di banda del bus di memoria . L'articolo collegato fa parte della serie che evidenzia problemi con una scarsa selezione delle chiavi in ​​cluster (INT vs GUID vs Sequential GUID) ma evidenzia la differenza che i byte possono fare.

Il messaggio prioritario riguarda le questioni di progettazione. La differenza non verrà visualizzata in un singolo database su un server adeguatamente specificato fino a quando non si raggiunge il territorio VLDB ma se è possibile salvare alcuni byte, perché non farlo.

Mi viene in mente l'ambiente descritto in una domanda precedente . Oltre 400 database, con dimensioni comprese tra 50mb e 50 GB, per istanza SQL. Scrubbing di pochi byte per record, per tabella, per database in quell'ambiente potrebbe fare una differenza significativa.

Oltre alle altre risposte ...

Le righe e le voci di indice sono memorizzate in 8k pagine. Quindi un milione di righe a 3 byte per riga non è 3 MB sul disco: influisce sul numero di righe per pagina ("densità di pagina").

Lo stesso vale per nvarchar a varchar, smalldatetime a datetime, int a tinyint ecc

Modifica, giugno 2013

http://sqlblog.com/blogs/joe_chang/archive/2013/06/16/load-test-manifesto.aspx

Questo articolo afferma

I criteri importanti sono la cardinalità e il rapporto da pagina a riga.

Quindi, la scelta del tipo di dati è importante

Non è solo l'archiviazione di tabelle che è una considerazione. Se si utilizzano gli indici in cui la colonna int fa parte di una chiave composta, si desidera naturalmente che le pagine dell'indice siano il più complete possibile, poiché il risultato delle voci dell'indice è il più piccolo possibile.

Mi sarei sicuramente aspettato di scoprire che esaminare le voci dell'indice nelle pagine BTREE sarebbe un po 'più veloce con tipi di dati più piccoli. Tuttavia, qualsiasi VARCHAR coinvolto nelle voci di indice compenserebbe (annullerebbe) i guadagni di prestazioni dall'uso di TINYINT su INT.

Ciononostante, se le voci di indice hanno voci composte e tutte sono numeri interi, più piccoli sono numeri interi a byte, migliore e più veloce.

Tutto diventa più complesso quando i database diventano più grandi:

• le finestre di manutenzione devono essere ingrandite o riprogrammate
• backup (il backup completo di fine giornata diventa un assurdo dispendio di tempo, quindi è necessario un backup differenziale o addirittura log e fare l'intero una volta alla settimana, forse una volta al mese)
• le manutenzioni delle prestazioni diventano un dispendio di tempo (la creazione di un indice su una tabella multi-milione di righe non richiede poco tempo per l'esecuzione) e deve essere riprogrammata e peggiora se la tabella è ampia ...
• E trasmettere quel backup da 100 Gb attraverso la rete non è ciò che chiamo un gioco da ragazzi - specialmente se la rete (per qualche ragione sconosciuta) è testarda a lasciare cadere la connessione sul segno da 75 Gb ... (è successo con un'installazione che stavo lavorando che stava eseguendo il backup su un'unità mappata sulla rete - rete) ...

E quali tipi di dati hanno a che fare con questo? QUALUNQUE COSA. L'uso di dimensioni di riga più grandi del necessario consente di riempire le pagine del database prima del necessario o addirittura di sprecare spazio se le dimensioni della riga sono tali che non è possibile registrare più di un record sulla pagina. Il risultato sono più pagine necessarie per la scrittura e la lettura, più memoria RAM viene utilizzata per memorizzare nella cache (i record più grandi richiedono memoria più grande). E poiché i tipi di dati sono specificati più grandi del necessario dal disco, gli indici subiranno lo stesso problema, specialmente se si raggruppa quella chiave primaria composita da 2 colonne BIGINT poiché qualsiasi altro indice creato copierà implicitamente quella chiave primaria nella loro definizione.

Se sai che alcune colonne in una tabella che avranno milioni di righe o addirittura una piccola tabella che verranno convertite in più milioni di righe che non richiedono un numero intero di 4 byte per memorizzare i loro dati, ma un 2 byte sarebbe basta - usa SMALLINT . Se i valori nell'intervallo 0-255 sono sufficienti, TINYINT . Una bandiera sì / no? C'è BIT .

Mentre per tinyintvs intci sono chiare differenze come spazio su disco, suddivisioni di pagina e tempi di manutenzione, non ci sarebbe nessuno di questi per varchar.

Quindi perché non dichiarare tutti i campi di testo come varchar(4000), poiché utilizzerà comunque solo lo spazio necessario? Ancora di più ti verrà garantito che i tuoi dati non verranno mai troncati.

La risposta è ovviamente:

1. Chiarimento delle tue intenzioni (poiché nessuno capirà perché un campo nome dovrebbe contenere 4000 caratteri)
2. Convalida come vuoi assicurarti che nessuno inserisca un'intera biografia come nome.

Questi stessi motivi si applicano tinyintanche a.