Dit is gebaseerd op een hoofdmisverstand van de innerlijke werking van Postgres en EAV-ontwerpen .
Als u geen honderden verschillende velden of een dynamische set attribuuttypen heeft, gebruikt u een enkele tabel met alle kolommen - behalve voor databasenormalisatie
. Kolommen zonder waarde worden gevuld met NULL .
Null-opslag is erg goedkoop , bezet 1 bit per kolom in de tabel voor de null-bitmap, meestal toegewezen in eenheden van 8 bytes om 64 kolommen te dekken. Zie:
Een aparte rij voor een enkele extra attribuut neemt minstens . in beslag een extra 36 bytes .
4 bytes item identifier 23 bytes heap tuple header 1 byte padding 8 bytes minimum row data size
Meestal meer vanwege opvulling en extra overhead.
Er zouden honderden verschillende, dunbevolkte kolommen moeten zijn voordat zo'n log EAV-ontwerp zou kunnen betalen - en hstore
of jsonb
in Postgres 9.4 zouden superieure oplossingen zijn voor dat . Er is nauwelijks ruimte tussenin voor je ontwerp, en als er was, zou je waarschijnlijk een enum
voor het type.
Tegelijkertijd zijn zoekopdrachten ingewikkelder en duurder. We zitten hier in een lastig parket.
Gebruik in plaats daarvan een tabelindeling zoals deze:
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
);
Nauw verwant antwoord met meer advies: