Modul unei coloane generate stabilește când se plătește calculul

O coloană generată îi dă unei valori derivate un loc în schemă. Alegerea modului stabilește și când face baza de date calculul. Coloanele virtuale mută calculul la citire; cele stocate îl fac la scriere și păstrează rezultatul. Precizați alegerea atunci când exprimă o presupunere importantă despre utilizare, în loc să lăsați o valoare implicită să țină locul deciziei de proiectare.

În această retrospectivă din noiembrie 2026, punctul de pornire istoric este PostgreSQL 18 beta 2, anunțat la 17 iulie 2025. Era o invitație la testarea unor sarcini reprezentative, cu avertisment explicit împotriva folosirii versiunii beta în producție. Nu era primul anunț despre coloanele generate virtuale și nici lansarea versiunii stabile PostgreSQL 18.

Separați versiunea de test de contractul final

Anunțul beta 1 din 8 mai enumera deja coloanele generate virtuale printre funcționalitățile planificate. Notele versiunii 18 indică 25 septembrie 2025 ca dată a lansării stabile. Dacă păstrați datele separate, retrospectiva poate folosi documentația finală fără să pretindă că întregul contract era deja stabil în iulie.

Documentația coloanelor generate din versiunea 18, consultată în noiembrie 2026, descrie modul virtual drept implicit. VIRTUAL și STORED precizează alegerea. Documentația este legată de o versiune majoră, dar rămâne întreținută; nu este o copie înghețată a manualului beta din iulie.

Valoarea implicită permite definiții concise. Alegerea explicită ajută atunci când viitorii cititori au nevoie să înțeleagă unde se face calculul. Niciuna nu dovedește un avantaj de performanță. Baza de date definește mecanismul, iar numai tiparele de citire și scriere ale aplicației stabilesc dacă acesta servește bine produsul.

Costul urmează folosirea valorii

Luați exemplul ipotetic al unui tabel cu o măsurătoare de bază și o conversie derivată între unități. O definiție virtuală poate exprima conversia fără să păstreze o a doua valoare în rând. Dacă valoarea derivată este cerută rar, calculul la citire poate fi atractiv. Argumentul este că reprezentarea stocată nu are nevoie să includă acea valoare derivată, nu că orice interogare devine mai rapidă.

Luați apoi o expresie derivată costisitoare, cerută repetat. Calculul la scrierea rândurilor poate fi preferabil recalculării la citire. Coloana stocată consumă spațiu și cere calcul la scriere, dar costurile pot fi rezonabile când susțin citirile importante. Acesta este un raționament despre utilizare, nu o măsurătoare locală pentru vreunul dintre moduri.

Frecvența citirilor nu ajunge singură. Întrebați ce citiri cer efectiv valoarea derivată și cum se raportează cererea la schimbările datelor de bază. Un ecran operațional care are rareori nevoie de valoare creează alt compromis decât un export repetat care depinde de ea. Un singur raport calculat pentru întreaga activitate a bazei poate ascunde familia de interogări care contează cel mai mult pentru utilizatori.

Aceeași precizie se aplică spațiului. Afirmația documentației că o coloană generată virtuală nu ocupă spațiu descrie valoarea coloanei. Nu este o măsurătoare a dimensiunii totale a unei anumite instalări. Celelalte obiecte din schemă și activitatea aplicației contează în continuare. Articolul nu raportează execuții în baza de date, comparații de dimensiuni sau rezultate de performanță.

Restricțiile expresiei pot decide mai întâi modul

Ambele moduri impun restricții expresiei de generare. Versiunea 18 cere funcții imuabile, exclude subinterogările și referințele în afara rândului curent. Expresia nu poate face referire la altă coloană generată. Coloanele de sistem sunt excluse, cu excepția tableoid. O coloană generată nu poate avea nici valoare implicită sau definiție de identitate și nu poate face parte din cheia de partiționare.

Coloanele virtuale adaugă o restricție importantă: nu pot avea tipuri definite de utilizator, iar expresiile lor nu pot apela funcții sau tipuri definite de utilizator, nici indirect, prin operatori sau conversii de tip. Coloanele stocate nu au această restricție suplimentară. Sunt condiții de eligibilitate a schemei, nu simple sfaturi de reglare. Un argument despre utilizare nu poate face validă o expresie neacceptată.

Pentru o modificare propusă a schemei, examinați expresia înainte să estimați economii. O conversie cu operații obișnuite predefinite diferă de un calcul de afaceri implementat într-o funcție proprie. Dacă acesta din urmă nu este eligibil pentru generare virtuală, echipa are nevoie de altă proiectare sau de o definiție stocată care îndeplinește cerințele aplicabile ei.

Imuabilitatea limitează și sensul câmpului. O valoare derivată din ora curentă sau din starea schimbătoare a altui tabel nu este o expresie obișnuită eligibilă pentru generare. Tratarea ei ca funcție deterministă a rândului ar descrie greșit regula de afaceri. Proiectarea potrivită poate cere o interogare, un sumar întreținut sau alt mecanism explicit de actualizare.

Coloanele generate se deosebesc și de valorile implicite. Valoarea implicită se folosește la inserare când nu este furnizată una; valoarea generată se calculează după regula sa și nu poate fi înlocuită printr-o valoare obișnuită transmisă la scriere. Distincția contează când un import se așteaptă să trimită propriul rezultat de referință. Schimbarea schemei poate modifica contractul de scriere chiar dacă numele câmpului rămâne cunoscut.

Legați decizia de un anumit câmp derivat

O propunere utilă de evaluare precizează expresia, interogările și scrierile comparate. Ar trebui să păstreze distribuții ale intrărilor și tipare de cereri reprezentative. Dacă produsul depinde de latența primului ecran, includeți acel traseu; dacă valoarea apare mai ales în rapoarte generate prin prelucrare în loturi, evaluați acea utilizare. Sunt verificări sugerate pentru un mediu autorizat, nu teste făcute pentru acest articol.

Contraargumentul cel mai puternic față de alegerea explicită și evaluare este simplitatea. O expresie eligibilă, ieftină, folosită rar într-o aplicație cu solicitări modeste poate fi potrivită pentru modul virtual implicit fără un studiu elaborat. Este rezonabil când responsabilul înțelege presupunerile. Scopul este o decizie proporțională, nu cerința unui test de performanță pentru fiecare linie din schemă.

O expresie costisitoare și citită frecvent merită altă discuție. Păstrarea modului STORED poate fi o alegere intenționată pentru predictibilitatea calculului la citire, nu rezistență la o funcționalitate nouă. La fel, păstrarea unei valori derivate aproape niciodată citite poate merita reanalizată. Niciun mod nu îndeamnă la optimizarea tuturor câmpurilor în aceeași direcție.

Pentru dezvoltare software la comandă, includeți modul ales și presupunerea despre utilizare în analiza schemei. Întrebarea diferă de cea despre înlocuirea unui index prin skip scan: aici decideți când se calculează o valoare derivată și dacă expresia ei este eligibilă. Reanalizați alegerea când produsul schimbă folosirea câmpului, pe baza dovezilor despre traseul efectiv deservit.