Dette er baseret på en principiel misforståelse af de indre funktioner i Postgres og EAV-designs .
Hvis du ikke har hundredvis af forskellige felter eller et dynamisk sæt af attributtyper, skal du bruge en enkelt tabel med alle kolonner - undtagen databasenormalisering
. Kolonner uden værdi er fyldt med NULL .
Nul opbevaring er meget billig , optager 1 bit kolonne i tabellen for null bitmap, typisk tildelt i enheder på 8 bytes til at dække 64 kolonner. Se:
En separat række for en enkelt yderligere attribut optager mindst yderligere 36 bytes .
4 bytes item identifier 23 bytes heap tuple header 1 byte padding 8 bytes minimum row data size
Typisk mere på grund af polstring og ekstra overhead.
Der skulle være hundredvis af forskellige, tyndt befolkede kolonner, før et så uhåndterligt EAV-design kunne betale sig - og hstore
eller jsonb
i Postgres 9.4 ville være overlegne løsninger til det . Der er næsten ikke plads imellem til dit design, og hvis der var, ville du sandsynligvis bruge en enum
for typen.
Samtidig er forespørgsler mere komplicerede og dyre. Vi er i en trang position her.
Brug i stedet et tabellayout som dette:
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ært beslægtet svar med flere råd: