Dies beruht auf einem grundlegenden Missverständnis des Innenlebens von Postgres und EAV-Designs .
Wenn Sie nicht über Hunderte von verschiedenen Feldern oder einen dynamischen Satz von Attributtypen verfügen, verwenden Sie eine einzelne Tabelle mit allen Spalten - außer Datenbanknormalisierung
. Spalten ohne Wert werden mit NULL gefüllt .
Null-Storage ist sehr günstig , belegt 1 Bit pro Spalte in der Tabelle für die Null-Bitmap, typischerweise in Einheiten von 8 Bytes zugewiesen, um 64 Spalten abzudecken. Siehe:
Eine separate Zeile für eine Single zusätzliches Attribut belegt mindestens weitere 36 Bytes .
4 bytes item identifier 23 bytes heap tuple header 1 byte padding 8 bytes minimum row data size
In der Regel mehr aufgrund von Polsterung und zusätzlichem Overhead.
Es müsste Hunderte von verschiedenen, spärlich gefüllten Spalten geben, bevor sich ein so unhandliches EAV-Design auszahlen könnte – und hstore
oder jsonb
in Postgres 9.4 wären bessere Lösungen dafür da . Dazwischen ist kaum Platz für Ihr Design und wenn wäre, würden Sie wahrscheinlich einen enum
für den Typ.
Gleichzeitig sind Abfragen komplizierter und teurer. Wir sind hier in einer schwierigen Lage.
Verwenden Sie stattdessen ein Tabellenlayout wie dieses:
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
);
Eng verwandte Antwort mit mehr Ratschlägen:
