Кое е по-ефективно smallint или character(10)?

Бих казал, че добавянето на изкуствен smallint първичният ключ би бил по-евтин по отношение на пространството за съхранение, ако таблицата е внимателно проектирана.

smallint отнема 2 байта, докато character(10) (което, противно на интуицията, е varlena ), съдържащи ASCII символи, ще заемат 14 байта.

В таблицата допълнителните 2 байта биха били загуба, но не забравяйте, че ще имате индекс в колоната с първичен ключ. Така че индексираната стойност всъщност ще се съхранява два пъти:веднъж в таблицата, веднъж в индекса.

За по-голяма простота, нека игнорираме заглавките на кортежи и други допълнителни разходи.

• Използването на ISBN като първичен ключ ще струва допълнителни 14 байта на ред в таблицата.

• Добавяне на smallint първичен ключ ще добави два байта към таблицата и два към индекса, което прави общо четири добавени байта.

Така че добавяне на smallint първичен ключ трябва да спести място .

Не трябва да пренебрегвате проблемите с подравняването. Всички типове данни се съхраняват на адреси в паметта, които са кратни на определени степени на две. Това се изисква от архитектурите на процесорите. smallint обикновено има подравняване 2, character има подравняване 1, докато например timestamp има подравняване 8.

Така че, ако вашата таблица е дефинирана като

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

Тогава данните в таблицата ще изглеждат така:

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

Редът е подравнен на 8-байтова граница и шестте байта от края, ако id до началото на issue_time ще бъдат празни „запълващи байтове“.

Така че, за да се възползвате максимално от него, ще трябва да обмислите в какъв ред дефинирате колоните.

Защо всичко това не е много уместно в действителност:

Таблица с 5000 или 10000 записа е малка, независимо от всичко.

Всеки изразходван за оптимизиране на пространството тук е в най-добрия случай ненужна микрооптимизация.

Но това, което може да е умна идея на масата за планиране, може лесно да има обратен ефект по-късно:Ако – различно от това, което очаквате – искате да съхраните 70 000 книги в таблицата, ще откриете, че smallint няма да е достатъчно, дори ако разрешите отрицателен id с. Болката, която ще трябва да понесете, когато трябва да промените типа данни на първичен ключ и всички външни ключове, които го препращат в активна система, далеч ще надхвърли всяко удоволствие, което получавате от спестяването на около 100 KB чрез умни оптимизации.