Vilket är effektivare smallint eller karaktär(10)?

Jag skulle säga att lägga till en artificiell smallint primärnyckeln skulle vara billigare när det gäller lagringsutrymme, om bordet är noggrant utformat.

En smallint tar 2 byte, medan ett character(10) (vilket är, kontraintuitivt, en varlena ) som innehåller ASCII-tecken, kommer att förbruka 14 byte.

I tabellen skulle de extra 2 byten vara slöseri, men glöm inte att du kommer att ha ett index på primärnyckelkolumnen. Så det indexerade värdet kommer faktiskt att lagras två gånger:en gång i tabellen, en gång i indexet.

Låt oss för enkelhetens skull ignorera tupelhuvuden och annan overhead.

• Att använda ISBN som primärnyckel kommer att kosta ytterligare 14 byte per tabellrad.

• Lägga till en smallint primärnyckeln lägger till två byte till tabellen och två till indexet, vilket ger totalt fyra tillagda byte.

Så lägger du till en smallint primärnyckel bör spara utrymme .

Du bör inte ignorera anpassningsproblem. Alla datatyper lagras på minnesadresser som är multiplar av vissa potenser av två. Detta krävs av processorernas arkitekturer. En smallint har vanligtvis justering 2, character har justering 1, medan till exempel timestamp har riktning 8.

Så om din tabell är definierad som

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

Då skulle tabelldata se ut så här:

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

Raden är justerad vid en 8-bytegräns, och de sex byten från slutet om id till början av issue_time kommer att vara tomma "padding bytes".

Så för att få ut det mesta av det måste du överväga i vilken ordning du definierar kolumnerna.

Varför allt detta inte är särskilt relevant i verkligheten:

En tabell med 5000 eller 10000 poster är liten, oavsett vad.

Allt som går åt till att optimera utrymmet här är i bästa fall onödig mikrooptimering.

Men det som kan vara en smart idé på planeringsbordet kan lätt slå tillbaka senare:Om du – annorlunda än vad du förväntar dig – vill lagra 70 000 böcker i tabellen, kommer du att upptäcka att en smallint kommer inte att räcka, även om du tillåter negativt id s. Smärtan du kommer att behöva utstå när du måste ändra datatypen för en primärnyckel och alla främmande nycklar som refererar till den i ett livesystem kommer vida uppväga all glädje du får av att spara cirka 100 KB genom smarta optimeringar.