Řekl bych, že přidání umělého smallint
primární klíč by byl levnější z hlediska úložného prostoru, pokud by byl stůl pečlivě navržen.
smallint
trvá 2 bajty, zatímco character(10)
(což je, proti intuici, varlena
) obsahující znaky ASCII zabere 14 bajtů.
V tabulce by byly 2 bajty navíc zbytečné, ale nezapomeňte, že budete mít index ve sloupci primárního klíče. Takže indexovaná hodnota bude ve skutečnosti uložena dvakrát:jednou v tabulce, jednou v indexu.
Pro jednoduchost ignorujme n-ticová záhlaví a další režii.
-
Použití ISBN jako primárního klíče bude stát dalších 14 bajtů na řádek tabulky.
-
Přidání
smallint
primární klíč přidá dva bajty do tabulky a dva do indexu, takže celkem čtyři přidané bajty.
Takže přidání smallint
primární klíč by měl šetřit místo .
Problémy se zarovnáním byste neměli ignorovat. Všechny datové typy jsou uloženy na adresách paměti, které jsou násobky určitých mocnin dvou. To vyžadují architektury procesorů. smallint
obvykle má zarovnání 2, character
má zarovnání 1, zatímco například timestamp
má zarovnání 8.
Pokud je tedy vaše tabulka definována jako
CREATE TABLE book (
id smallint PRIMARY KEY,
issue_time timestamp with time zone,
isbn character(10)
);
Data tabulky by pak vypadala takto:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | |X|X|X|X|X|X| | | | | | | | | ... (ISBN omitted)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
id padding issue_time
Řádek je zarovnán na hranici 8 bajtů a šest bajtů od konce, pokud id
na začátek issue_time
bude prázdné „vyplňovací bajty“.
Chcete-li jej tedy využít na maximum, budete muset zvážit, v jakém pořadí definujete sloupce.
Proč to všechno není ve skutečnosti příliš relevantní:
Tabulka s 5000 nebo 10000 položkami je bez ohledu na to malá.
Veškeré vynaložené prostředky na optimalizaci prostoru jsou v nejlepším případě zbytečnou mikrooptimalizací.
Ale to, co může být chytrý nápad na plánovacím stole, se může později snadno vymstít:Pokud – na rozdíl od toho, co očekáváte – chcete na stůl uložit 70 000 knih, zjistíte, že smallint
nebude stačit, i když povolíte záporné id
s. Bolest, kterou budete muset vydržet, když budete muset změnit datový typ primárního klíče a všech cizích klíčů, které na něj odkazují v živém systému, zdaleka převáží jakékoli potěšení, které získáte z ušetření nějakých 100 KB chytrými optimalizacemi.