PostgreSQL suporton varje të kolonave — një kolone e vetme mund të mbajë shumë vlera të të njëjtit tip. Kjo është një veçori karakteristike e Postgres-it e dobishme për ruajtjen e listave (tags, role, pikë) pa një tabelë të veçantë, me operatorë dhe funksione për kërkimin.
posts (
id SERIAL ,
title TEXT,
tags TEXT[]
);
posts (title, tags)
(, [, ]),
(, );
Sintaksa type[] deklaron një kolonë varjeje. Ju futni me ARRAY[...] ose '{...}' sintaksën e literalit.
-- 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
Operatorë si ANY (përmban një vlerë), @> (përfshirje), dhe && (mbivendosje), plus funksionet si unnest (zgjerimi në rreshta) dhe array_agg (grumbullimi i rreshtave në një varje), e bëjnë varjet të kërkueshme.
-- 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.
Kolonat e varjeve janë një veçori karakteristike dhe e dobishme e PostgreSQL-it, dhe përqasja e tyre është e vlefshme si për shfrytëzimin e aftësive të Postgres-it ashtu edhe për marrjen e vendimeve të zëna të dizajnit.
Varjet ju lejojnë të ruani shumë vlera në një kolonë të vetme (tags, role, lista) pa një tabelë të veçantë — e përshtatshme për lista të thjeshta të lidhura ngushtë me një rresht.
Përqasja si të përcaktoni, futni, dhe veçanërisht kërkoni varje (operatorë si ANY për anëtarësinë, @> për përfshirje, && për mbivendosje, dhe funksionet si unnest për të zgjeruar varjet në rreshta) është e nevojshme për t'i përdorur ato në mënyrë efektive, dhe njohja se indekset GIN e bëjnë kërkimin e varjeve efikas është e rëndësishme për performancën.
Njësoj e rëndësishme është gjykimi i dizajnit në lidhje me kur të përdoren varjet kundrejt një tabele të lidhur të normalizuar: varjet janë të përshtatshme për lista të thjeshta që nuk keni nevojë t'i kërkoni, bashkoni, ose mirëmbani në mënyrë relacionale, por ato mund të shkelën parimet e normalizimit dhe të bëhen të vështira kur duhet të kërkoni vlera individuale, të bashkoheni në to, ose të menaxhoni një listë komplekse/të madhe — në këtë rast, një tabelë e lidhur e veçantë është zgjedhja më e mirë e normalizuar.
Përqasja e këtij kompromisi (varje për lehtësi me lista të thjeshta të lidhura, tabelat e veçanta për të dhënat e menaxhuara në mënyrë relacionale) pasqyron gjykimin e zëna të dizajnit.
Meqenëse varjet janë një veçori e dobishme dhe karakteristike e Postgres-it që mund të thjeshton dizajnet e caktuara (duke shmangur një tabelë bashkim për lista të thjeshta) por mund të keqpërdoren (denormalizimi i të dhënave që duhet të jenë relacionale), përqasja e kolonave të varjeve — si të përcaktoni, kërkoni, dhe indeksoni ato, dhe në mënyrë vendimtare kur janë të përshtatshme kundrejt kohës kur një tabelë e normalizuar është më e mirë — është njohje e vlefshme dhe praktikisht relevante për projektimin e skemave të Postgres-it që përdorin qasjen e duhur për secilin lloj të dhënash me shumë vlera.