Detta är baserat på ett huvudsakligt missförstånd av Postgres inre funktioner och EAV-designer .
Om du inte har hundratals olika fält eller en dynamisk uppsättning attributtyper, använd en enskild tabell med alla kolumner - förutom databasnormalisering
. Kolumner utan värde fylls med NULL
.
Nulllagring är mycket billig , upptar 1 bit per kolumn i tabellen för noll-bitmappen, vanligtvis allokerad i enheter om 8 byte för att täcka 64 kolumner. Se:
En separat rad för en singel ytterligare attribut upptar minst ytterligare 36 byte .
4 bytes item identifier 23 bytes heap tuple header 1 byte padding 8 bytes minimum row data size
Vanligtvis mer, på grund av stoppning och extra overhead.
Det skulle behöva finnas hundratals olika, glest befolkade kolumner innan en så otymplig EAV-design kunde betala sig - och hstore
eller jsonb
i Postgres 9.4 skulle vara överlägsna lösningar för det . Det finns knappt något utrymme däremellan för din design och if det fanns, skulle du förmodligen använda en enum
för typen.
Samtidigt är frågor mer komplicerade och dyra. Vi har det trångt här.
Använd istället en tabelllayout så här:
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
);
Närbesläktat svar med fler råd: