Je dirais que l'ajout d'un smallint artificiel clé primaire serait moins cher en termes d'espace de stockage, si la table est soigneusement conçue.
Un smallint prend 2 octets, tandis qu'un character(10) (qui est, contre-intuitivement, un varlena ) contenant des caractères ASCII, consommera 14 octets.
Dans la table, les 2 octets supplémentaires seraient du gaspillage, mais n'oubliez pas que vous aurez un index sur la colonne de la clé primaire. Ainsi, la valeur indexée sera en fait stockée deux fois :une fois dans la table, une fois dans l'index.
Par souci de simplicité, ignorons les en-têtes de tuple et autres surcharges.
-
L'utilisation de l'ISBN comme clé primaire coûtera 14 octets supplémentaires par ligne de tableau.
-
Ajouter un
smallintla clé primaire ajoutera deux octets à la table et deux à l'index, soit un total de quatre octets supplémentaires.
Alors ajoutez un smallint la clé primaire devrait économiser de l'espace .
Vous ne devez pas ignorer les problèmes d'alignement. Tous les types de données sont stockés à des adresses mémoire qui sont des multiples de certaines puissances de deux. Ceci est requis par les architectures des processeurs. Un smallint a généralement l'alignement 2, character a l'alignement 1, alors que par exemple timestamp a l'alignement 8.
Donc, si votre table est définie comme
CREATE TABLE book (
id smallint PRIMARY KEY,
issue_time timestamp with time zone,
isbn character(10)
);
Les données du tableau ressembleraient alors à ceci :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | |X|X|X|X|X|X| | | | | | | | | ... (ISBN omitted)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
id padding issue_time
La ligne est alignée sur une limite de 8 octets et les six octets à partir de la fin si id au début de issue_time sera vide "octets de remplissage".
Donc, pour en tirer le meilleur parti, vous devrez considérer dans quel ordre vous définissez les colonnes.
Pourquoi tout cela n'est pas très pertinent en réalité :
Une table avec 5000 ou 10000 entrées est minuscule, quoi qu'il arrive.
Tout ce qui est dépensé pour optimiser l'espace ici est au mieux une micro-optimisation inutile.
Mais ce qui peut être une idée intelligente sur la table de planification peut facilement se retourner contre vous plus tard :si - contrairement à ce que vous attendez - vous souhaitez stocker 70 000 livres dans la table, vous constaterez qu'un smallint ne suffira pas, même si vous autorisez un id négatif s. La douleur que vous aurez à endurer lorsque vous devrez changer le type de données d'une clé primaire et de toutes les clés étrangères qui y font référence dans un système en direct l'emportera de loin sur le plaisir que vous aurez à économiser quelque 100 Ko grâce à des optimisations intelligentes.
