Cum funcționează coloanele cu tablouri în PostgreSQL?

Question

Accepted Answer

PostgreSQL acceptă coloane de tip **array** — o singură coloană poate conține *multiple valori* de același tip. Aceasta este o caracteristică distinctivă a Postgres utilă pentru stocarea listelor (etichetă, roluri, punctaje) fără o tabel separat, cu operatori și funcții pentru interogare.

## Definirea și inserarea tablourilor

```sql
CREATE TABLE posts (
  id SERIAL PRIMARY KEY,
  title TEXT,
  tags TEXT[]                         -- an array of text
);

INSERT INTO posts (title, tags) VALUES
  ('Hello', ARRAY['ruby', 'web']),    -- ARRAY[] syntax
  ('World', '{"news", "tech"}');       -- or curly-brace literal
```

Sintaxa `type[]` declară o coloană de tip array. Inserați cu sintaxa literală `ARRAY[...]` sau `'{...}'`.

## Interogarea tablourilor

```sql
-- 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
```

Operatori precum `ANY` (conține o valoare), `@>` (incluziune), și `&&` (suprapunere), plus funcții precum `unnest` (expandare în rânduri) și `array_agg` (agregare rânduri într-un array), fac tablourile interogabile.

## Indexarea tablourilor (GIN)

```sql
-- 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
```

## Când se folosesc tablouri (și când nu)

```text
✓ 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.
```

## De ce contează

Coloanele cu array sunt o caracteristică distinctivă și utilă a PostgreSQL, iar înțelegerea lor este valoroasă atât pentru a valorifica capacitățile Postgres cât și pentru a lua decizii solide de proiectare.

Tablourile vă permit să stocați **multiple valori într-o singură coloană** (etichetă, roluri, liste) fără o tabel separat — convenabil pentru liste simple strâns legate de un rând.

Înțelegerea modului de definire, inserare, și mai ales **interogare** a tablourilor (operatori precum `ANY` pentru appartență, `@>` pentru incluziune, `&&` pentru suprapunere, și funcții precum `unnest` pentru a expanda tablouri în rânduri) este necesară pentru a le folosi eficient, și știind că **indexurile GIN** fac interogările de tablouri eficiente este important pentru performanță.

Egal de important este **judecata de proiectare** de a decide când să folosiți tablouri versus o tabel normalizată aferentă: tablourile sunt convenabile pentru liste simple pe care nu trebuie să le interogați, să le conectați, sau să le mențineți relațional, dar pot viola principiile normalizării și devin greoaie atunci când trebuie să interogați valori individuale, să le conectați, sau să gestionați o listă complexă/mare — caz în care o tabel separată aferentă este alegerea mai bună și normalizată.

Înțelegerea acestui compromis (tablouri pentru comoditate cu liste simple legate, tabele separate pentru date administrate relațional) reflectă o judecată de proiectare solidă.

Deoarece tablourile sunt o caracteristică utilă și distinctivă a Postgres care poate simplifica anumite proiecte (evitând un tabel de joncțiune pentru liste simple) dar pot fi folosite greșit (denormalizând date care ar trebui să fie relaționale), înțelegerea coloanelor cu array — cum să le definiți, să le interogați și să le indexați, și în esență când sunt apropriate versus când o tabel normalizată este mai bună — este cunoaștere valoroasă și practic relevantă pentru proiectarea schemelor Postgres care folosesc abordarea corectă pentru fiecare fel de date cu multiple valori.