Diría que agregar un smallint artificial la clave principal sería más económica en términos de espacio de almacenamiento, si la tabla se diseña cuidadosamente.
Un smallint ocupa 2 bytes, mientras que un character(10) (que es, contrariamente a la intuición, una varlena ) que contiene caracteres ASCII, consumirá 14 bytes.
En la tabla, los 2 bytes adicionales serían un desperdicio, pero no olvide que tendrá un índice en la columna de la clave principal. Entonces, el valor indexado en realidad se almacenará dos veces:una vez en la tabla, una vez en el índice.
En aras de la simplicidad, ignoremos los encabezados de tupla y otros gastos generales.
-
Usar el ISBN como clave principal costará 14 bytes adicionales por fila de la tabla.
-
Agregar un
smallintla clave principal agregará dos bytes a la tabla y dos al índice, haciendo un total de cuatro bytes agregados.
Así que agregar un smallint la clave principal debe ahorrar espacio .
No debe ignorar los problemas de alineación. Todos los tipos de datos se almacenan en direcciones de memoria que son múltiplos de ciertas potencias de dos. Esto es requerido por las arquitecturas de los procesadores. Un smallint normalmente tiene alineación 2, character tiene alineación 1, mientras que por ejemplo timestamp tiene alineación 8.
Entonces, si su tabla está definida como
CREATE TABLE book (
id smallint PRIMARY KEY,
issue_time timestamp with time zone,
isbn character(10)
);
Entonces los datos de la tabla se verían así:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | |X|X|X|X|X|X| | | | | | | | | ... (ISBN omitted)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
id padding issue_time
La fila está alineada en un límite de 8 bytes y los seis bytes desde el final si id al comienzo de issue_time estará vacío "bytes de relleno".
Entonces, para aprovecharlo al máximo, deberá considerar en qué orden define las columnas.
Por qué todo esto no es muy relevante en la realidad:
Una tabla con 5000 o 10000 entradas es diminuta, pase lo que pase.
Cualquier pensamiento gastado en optimizar el espacio aquí es, en el mejor de los casos, una microoptimización innecesaria.
Pero lo que puede ser una idea inteligente en la mesa de planificación puede resultar fácilmente contraproducente más tarde:si, a diferencia de lo que espera, desea almacenar 70000 libros en la mesa, encontrará que un smallint no será suficiente, incluso si permite una id negativa s. El dolor que tendrá que soportar cuando tenga que cambiar el tipo de datos de una clave principal y todas las claves externas que hacen referencia a ella en un sistema en vivo superará con creces cualquier placer que obtenga al ahorrar unos 100 KB mediante optimizaciones inteligentes.
