PostgreSQL obsługuje kolumny array — pojedyncza kolumna może zawierać wiele wartości tego samego typu. To charakterystyczna cecha Postgresa, przydatna do przechowywania list (tagów, ról, wyników) bez osobnej tabeli, z operatorami i funkcjami do wykonywania zapytań.
posts (
id SERIAL ,
title TEXT,
tags TEXT[]
);
posts (title, tags)
(, [, ]),
(, );
Syntaksa type[] deklaruje kolumnę tablicową. Wstawiasz wartości przy użyciu syntaksy ARRAY[...] lub literału '{...}'.
-- 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
Operatory takie jak ANY (zawiera wartość), @> (zawieranie), i && (przecięcie), oraz funkcje takie jak unnest (rozwinięcie na wiersze) i array_agg (agregacja wierszy do tablicy), czynią tablice możliwymi do przeszukania.
-- 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.
Kolumny z tablicami to charakterystyczna i przydatna cecha PostgreSQL, a zrozumienie ich jest wartościowe zarówno do wykorzystania możliwości Postgresa, jak i do podejmowania rozsądnych decyzji projektowych.
Tablice pozwalają przechowywać wiele wartości w jednej kolumnie (tagi, role, listy) bez osobnej tabeli — wygodnie dla prostych list ściśle związanych z wierszem.
Zrozumienie sposobu definiowania, wstawiania, a zwłaszcza wykonywania zapytań na tablicach (operatory takie jak ANY dla członkowstwa, @> dla zawierania, && dla przecięcia, i funkcje takie jak unnest do rozwinięcia tablic na wiersze) jest niezbędne do ich efektywnego użycia, a wiedza że indeksy GIN czynią zapytania na tablicach wydajnymi jest ważna dla wydajności.
Również ważna jest ocena projektowa kiedy używać tablic zamiast znormalizowanej powiązanej tabeli: tablice są wygodne dla prostych list, których nie musisz wykonywać zapytania, łączyć lub utrzymywać relacyjnie, ale mogą naruszać zasady normalizacji i stać się kłopotliwe gdy musisz wykonywać zapytania na poszczególnych wartościach, łączyć je lub zarządzać złożoną/dużą listą — w takim przypadku oddzielna powiązana tabela jest lepszym, znormalizowanym wyborem.
Zrozumienie tego kompromisu (tablice dla wygody z prostymi powiązanymi listami, oddzielne tabele dla danych zarządzanych relacyjnie) odzwierciedla rozsądną ocenę projektową.
Ponieważ tablice to przydatna, charakterystyczna cecha Postgresa, która może uprościć pewne projekty (unikając tabeli łącznikowej dla prostych list), ale mogą być niewłaściwie użyte (denormalizując dane, które powinny być relacyjne), zrozumienie kolumn array — jak je definiować, wykonywać na nich zapytania, indeksować je, i co kluczowe kiedy są odpowiednie a kiedy znormalizowana tabela jest lepsza — to wartościowa, praktycznie użyteczna wiedza do projektowania schematów Postgresa, które stosują właściwe podejście do każdego rodzaju wielowartościowych danych.