Lösung wie gewünscht
Während wir bei diesem unglücklichen Design bleiben, wäre die schnellste Abfrage mit crosstab()
, bereitgestellt durch das Zusatzmodul tablefunc
. Ausführliche Details in dieser verwandten Antwort:
Für die gestellte Frage:
SELECT * FROM crosstab(
$$SELECT e.id, ef.name, ef.value
FROM entry e
LEFT JOIN entry_fields ef
ON ef.entryid = e.id
AND ef.name = ANY ('{result,output,code,command}'::text[])
ORDER BY 1, 2$$
,$$SELECT unnest('{result,output,code,command}'::text[])$$
) AS ct (id int, result text, output text, code text, command text);
Datenbankdesign
Wenn Sie kein riesiges haben Anzahl verschiedener Felder wird es viel einfacher und effizienter um alle drei Tabellen zu einer einfachen Tabelle zusammenzuführen:
CREATE TABLE entry (
entry_id serial PRIMARY KEY
,field1 text
,field2 text
, ... more fields
);
Felder ohne Werte können NULL
sein . NULL
Speicher ist sehr günstig (grundsätzlich 1 Bit pro Spalte in der NULL-Bitmap):
- Wie viel Speicherplatz wird benötigt, um einen NULL-Wert mit postgresql DB zu speichern?
- Nullable ausführen Spalten belegen zusätzlichen Platz in PostgreSQL?
Selbst wenn Sie Hunderte verschiedener Spalten haben und nur wenige pro Eintrag gefüllt werden, verbraucht dies immer noch viel weniger Speicherplatz.
Ihre Abfrage wird trivial:
SELECT entry_id, result, output, code, command
FROM enty;
Wenn Sie zu viele Spalten haben und das nicht nur ein fehlgeleitetes Design ist (oft kann dies in viel weniger Spalten gefaltet werden), ziehen Sie die Datentypen hstore
oder json
/ jsonb
(in Postgres 9.4) für EAV
Speicher.
Maximum Columns per Table 250 - 1600 depending on column types
Betrachten Sie diese verwandte Antwort mit Alternativen:
Und diese Frage zu typischen Anwendungsfällen / Problemen von EAV-Strukturen auf dba.SE: