Jest to oparte na głównym nieporozumieniu wewnętrznego działania Postgresa i projektów EAV .
Jeśli nie masz setek różnych pól lub dynamicznego zestawu typów atrybutów, użyj jednej tabeli ze wszystkimi kolumnami - z wyjątkiem normalizacji bazy danych
. Kolumny bez wartości są wypełnione NULL .
Puste miejsce jest bardzo tanie , zajmując 1 bit na kolumnę w tabeli dla mapy bitowej o wartości null, zwykle przydzielanej w jednostkach po 8 bajtów w celu pokrycia 64 kolumn. Zobacz:
Oddzielny wiersz dla singli dodatkowy atrybut zajmuje co najmniej dodatkowe 36 bajtów .
4 bytes item identifier 23 bytes heap tuple header 1 byte padding 8 bytes minimum row data size
Zazwyczaj więcej ze względu na wypełnienie i dodatkowe obciążenie.
Musiałyby istnieć setki różnych, rzadko zapełnionych kolumn, zanim tak nieporęczny projekt EAV mógłby się opłacać – i hstore
lub jsonb
w Postgresie 9.4 byłoby lepszym rozwiązaniem dla tego . Prawie nie ma między nimi miejsca na Twój projekt, a jeśli był, prawdopodobnie używałbyś enum
dla typu.
Jednocześnie zapytania są bardziej skomplikowane i droższe. Jesteśmy w trudnej sytuacji.
Zamiast tego użyj takiego układu tabeli:
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
);
Ściśle powiązana odpowiedź z dodatkowymi poradami:
