Ceci est basé sur un malentendu principal du fonctionnement interne de Postgres et conceptions EAV .
Si vous n'avez pas des centaines de champs différents ou un ensemble dynamique de types d'attributs, utilisez une table unique avec toutes les colonnes - sauf pour normalisation de la base de données
. Les colonnes sans valeur sont remplies avec NULL .
Le stockage nul est très bon marché , occupant 1 bit par colonne dans la table pour le bitmap nul, généralement alloué en unités de 8 octets pour couvrir 64 colonnes. Voir :
Une ligne séparée pour un simple l'attribut supplémentaire occupe au moins un 36 octets supplémentaire .
4 bytes item identifier 23 bytes heap tuple header 1 byte padding 8 bytes minimum row data size
Généralement plus, en raison du rembourrage et des frais généraux supplémentaires.
Il devrait y avoir des centaines de colonnes différentes et peu peuplées avant qu'une conception EAV aussi lourde puisse payer - et hstore
ou jsonb
dans Postgres 9.4 seraient des solutions supérieures pour cela . Il n'y a pratiquement pas de place entre les deux pour votre conception, et si il y en avait, vous utiliseriez probablement un enum
pour le type.
Dans le même temps, les requêtes sont plus compliquées et coûteuses. Nous sommes dans une situation délicate ici.
Utilisez plutôt une disposition de tableau comme celle-ci :
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
);
Réponse étroitement liée avec plus de conseils :
