Qual è smallint o character(10) più efficiente?

Direi che aggiungendo un smallint artificiale chiave primaria sarebbe più economico in termini di spazio di archiviazione, se la tabella è progettata con cura.

Un smallint occupa 2 byte, mentre un character(10) (che è, controintuitivamente, un varlena ) contenente caratteri ASCII, consumerà 14 byte.

Nella tabella, i 2 byte in più sarebbero uno spreco, ma non dimenticare che avrai un indice nella colonna della chiave primaria. Quindi il valore indicizzato verrà effettivamente memorizzato due volte:una volta nella tabella, una volta nell'indice.

Per semplicità, ignoriamo le intestazioni delle tuple e altri costi generali.

• L'utilizzo dell'ISBN come chiave primaria costerà 14 byte in più per riga della tabella.

• Aggiunta di un smallint la chiave primaria aggiungerà due byte alla tabella e due all'indice, per un totale di quattro byte aggiunti.

Quindi aggiungendo un smallint la chiave primaria dovrebbe risparmiare spazio .

Non dovresti ignorare i problemi di allineamento. Tutti i tipi di dati sono archiviati in indirizzi di memoria multipli di determinate potenze di due. Ciò è richiesto dalle architetture dei processori. Un smallint in genere ha l'allineamento 2, character ha allineamento 1, mentre ad esempio timestamp ha allineamento 8.

Quindi, se la tua tabella è definita come

CREATE TABLE book (
   id smallint PRIMARY KEY,
   issue_time timestamp with time zone,
   isbn character(10)
);

Quindi i dati della tabella sarebbero simili a questo:

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | |X|X|X|X|X|X| | | | | | | | | ... (ISBN omitted)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 id    padding     issue_time

La riga è allineata a un limite di 8 byte e i sei byte dalla fine se id all'inizio di issue_time saranno "byte di riempimento" vuoti.

Quindi, per sfruttarlo al meglio, dovrai considerare in quale ordine definisci le colonne.

Perché tutto questo non è molto rilevante nella realtà:

Una tabella con 5000 o 10000 voci è minuscola, qualunque cosa accada.

Anche se speso per ottimizzare lo spazio qui è nella migliore delle ipotesi una micro-ottimizzazione non necessaria.

Ma quella che potrebbe essere un'idea intelligente sul tavolo della pianificazione può facilmente ritorcersi contro in seguito:se, a differenza di quanto ti aspetti, desideri archiviare 70000 libri nel tavolo, scoprirai che un smallint non sarà sufficiente, anche se consenti id negativo S. Il dolore che dovrai sopportare quando devi modificare il tipo di dati di una chiave primaria e tutte le chiavi esterne che fanno riferimento ad essa in un sistema live supereranno di gran lunga qualsiasi piacere che ottieni risparmiando circa 100 KB con ottimizzazioni intelligenti.