PostgreSQL unterstützt Array-Spalten — eine einzelne Spalte kann mehrere Werte desselben Typs enthalten. Dies ist eine charakteristische Postgres-Funktion, die zum Speichern von Listen (Tags, Rollen, Scores) ohne eine separate Tabelle nützlich ist, mit Operatoren und Funktionen zum Abfragen von Arrays.
posts (
id SERIAL ,
title TEXT,
tags TEXT[]
);
posts (title, tags)
(, [, ]),
(, );
Die type[]-Syntax deklariert eine Array-Spalte. Sie fügen mit ARRAY[...] oder '{...}'-Literal-Syntax ein.
-- ANY — does the array contain a value?
SELECT * FROM posts WHERE 'ruby' = ANY(tags);
-- @> containment — does the array contain ALL of these?
SELECT * FROM posts WHERE tags @> ARRAY['ruby', 'web'];
-- && overlap — do the arrays share ANY element?
SELECT * FROM posts WHERE tags && ARRAY['tech', 'news'];
-- access by index (1-based!) and length
SELECT tags[1], array_length(tags, 1) FROM posts;
-- unnest — expand an array into rows
SELECT id, unnest(tags) AS tag FROM posts; -- one row per tag
Operatoren wie ANY (enthält einen Wert), @> (Containment), und && (Überlappung), sowie Funktionen wie unnest (zu Zeilen erweitern) und array_agg (Zeilen in ein Array aggregieren), machen Arrays abfragbar.
-- a GIN index makes array containment/membership queries fast
CREATE INDEX idx_posts_tags ON posts USING GIN (tags);
-- now WHERE tags @> ARRAY['ruby'] uses the index
✓ USE for: simple lists tightly coupled to the row (tags, roles, a few scores)
where you don't need to query/join the individual values much
✗ AVOID when: you need to query, join, or maintain the values relationally,
or the list is large/complex → a separate related table (normalized) is better
→ Arrays are convenient but can violate normalization; use them judiciously.
Array-Spalten sind eine charakteristische und nützliche PostgreSQL-Funktion, und ihr Verständnis ist wertvoll, sowohl um die Fähigkeiten von Postgres zu nutzen als auch um fundierte Designentscheidungen zu treffen.
Arrays ermöglichen es Ihnen, mehrere Werte in einer einzelnen Spalte zu speichern (Tags, Rollen, Listen) ohne eine separate Tabelle — praktisch für einfache Listen, die eng an eine Zeile gekoppelt sind.
Das Verständnis dafür, wie Sie Arrays definieren, einfügen und besonders abfragen (Operatoren wie ANY für Zugehörigkeit, @> für Containment, && für Überlappung und Funktionen wie unnest, um Arrays in Zeilen zu erweitern), ist notwendig, um sie effektiv zu nutzen. Zu wissen, dass GIN-Indizes Array-Abfragen effizient machen, ist wichtig für die Leistung.
Genauso wichtig ist das Design-Urteil, wann Arrays versus eine normalisierte verwandte Tabelle verwendet werden: Arrays sind praktisch für einfache Listen, die Sie nicht abfragen, joinen oder relational verwalten müssen, aber sie können Normalisierungsprinzipien verletzen und unhandlich werden, wenn Sie einzelne Werte abfragen, auf ihnen joinen oder eine komplexe/große Liste verwalten müssen — in diesem Fall ist eine separate verwandte Tabelle die bessere, normalisierte Wahl.
Das Verständnis dieses Kompromisses (Arrays für Bequemlichkeit mit einfachen gekoppelten Listen, separate Tabellen für relational verwaltete Daten) spiegelt fundiertes Design-Urteil wider.
Da Arrays eine nützliche, charakteristische Postgres-Funktion sind, die bestimmte Designs vereinfachen kann (vermeiden einer Join-Tabelle für einfache Listen), aber auch missbräuchlich verwendet werden können (Denormalisierung von Daten, die relational sein sollten), ist das Verständnis von Array-Spalten — wie man sie definiert, abfragt und indiziert, und entscheidend wann sie angemessen sind versus wann eine normalisierte Tabelle besser ist — wertvoll, praktisch relevantes Wissen für die Gestaltung von Postgres-Schemas, die den richtigen Ansatz für jede Art von mehwertigen Daten verwenden.