Esto se basa en un malentendido principal del funcionamiento interno de Postgres y diseños EAV .
Si no tiene cientos de campos diferentes o un conjunto dinámico de tipos de atributos, use una tabla única con todas las columnas - excepto para normalización de bases de datos
. Las columnas sin valor se rellenan con NULL .
El almacenamiento nulo es muy barato , ocupando 1 bit por columna en la tabla para el mapa de bits nulo, normalmente asignado en unidades de 8 bytes para cubrir 64 columnas. Ver:
Una fila separada para un simple atributo adicional ocupa al menos 36 bytes adicionales .
4 bytes item identifier 23 bytes heap tuple header 1 byte padding 8 bytes minimum row data size
Por lo general, más, debido al relleno y la sobrecarga adicional.
Tendría que haber cientos de columnas diferentes y escasamente pobladas antes de que un diseño EAV tan difícil de manejar pudiera pagar, y hstore
o jsonb
en Postgres 9.4 serían soluciones superiores para eso . Apenas hay espacio intermedio para su diseño, y si hubo, probablemente estaría usando un enum
para el tipo.
Al mismo tiempo, las consultas son más complicadas y costosas. Estamos en un aprieto aquí.
En su lugar, utilice un diseño de tabla como este:
CREATE TABLE users (
users_id serial PRIMARY KEY
, salutation text
, given_name text
, surname text
, alias text
... (many) more columns
);
CREATE TABLE address (
address_id serial PRIMARY KEY
, users_id int REFERENCES users
, city text -- or separate TABLE city incl region_id etc. ...
, region_id int REFERENCES region
, address text
... (many) more columns
);
Respuesta estrechamente relacionada con más consejos:
