Colonne calcolate / calcolate / virtuali / derivate in PostgreSQL

PostgreSQL supporta colonne calcolate / calcolate, come MS SQL Server? Non riesco a trovare nulla nei documenti, ma poiché questa funzione è inclusa in molti altri DBMS, ho pensato che mi mancasse qualcosa.

Ad esempio: http://msdn.microsoft.com/en-us/library/ms191250.aspx

Le colonne generate fino a Postgres 11 non sono supportate, come definito nello standard SQL e implementato da alcuni RDBMS inclusi DB2, MySQL e Oracle. Né le simili "colonne calcolate" di SQL Server.

STOREDle colonne generate vengono introdotte con Postgres 12 . Esempio banale:

CREATE TABLE tbl (
  int1    int
, int2    int
, product bigint GENERATED ALWAYS AS (int1 * int2) STORED
);

db <> fiddle qui

VIRTUALcolonne generate possono venire con una delle successive iterazioni. (Non in Postgres 13, ancora).

Relazionato:

• La notazione degli attributi per la chiamata di funzione restituisce un errore

Fino ad allora , puoi emulare le VIRTUALcolonne generate con una funzione utilizzando l' attributo notation ( tbl.col) che assomiglia e funziona in modo molto simile a una colonna generata virtuale . Questa è un po 'una stranezza sintattica che esiste in Postgres per ragioni storiche e che sembra adattarsi al caso. Questa risposta correlata ha esempi di codice :

• Memorizzare la query comune come colonna?

Tuttavia, l'espressione (che sembra una colonna) non è inclusa in a SELECT * FROM tbl. Devi sempre elencarlo esplicitamente.

Può anche essere supportato con un indice di espressione corrispondente , a condizione che la funzione lo sia IMMUTABLE. Piace:

CREATE FUNCTION col(tbl) ... AS ...  -- your computed expression here
CREATE INDEX ON tbl(col(tbl));

alternative

In alternativa, è possibile implementare funzionalità simili con un VIEW, facoltativamente accoppiato con indici di espressione. Quindi SELECT *può includere la colonna generata.

Le STOREDcolonne calcolate "Persisted" ( ) possono essere implementate con i trigger in modo funzionalmente identico.

Le viste materializzate sono un concetto strettamente correlato, implementato da Postgres 9.3 .
Nelle versioni precedenti è possibile gestire manualmente le MV.

Si, puoi!! La soluzione dovrebbe essere facile, sicura e performante ...

Sono nuovo di postgresql, ma sembra che tu possa creare colonne calcolate utilizzando un indice di espressione , associato a una vista (la vista è opzionale, ma rende la vita un po 'più facile).

Supponiamo che il mio calcolo sia md5(some_string_field), quindi creo l'indice come:

CREATE INDEX some_string_field_md5_index ON some_table(MD5(some_string_field));

Ora, qualsiasi query su cui agisce MD5(some_string_field)utilizzerà l'indice anziché calcolarlo da zero. Per esempio:

SELECT MAX(some_field) FROM some_table GROUP BY MD5(some_string_field);

Puoi verificarlo con spiegare .

Tuttavia a questo punto ti affidi agli utenti della tabella che sanno esattamente come costruire la colonna. Per semplificarti la vita, puoi creare una VIEWversione aumentata della tabella originale, aggiungendo il valore calcolato come nuova colonna:

CREATE VIEW some_table_augmented AS 
   SELECT *, MD5(some_string_field) as some_string_field_md5 from some_table;

Ora tutte le query che utilizzano some_table_augmentedsaranno in grado di essere utilizzate some_string_field_md5senza preoccuparsi di come funziona .. ottengono solo buone prestazioni. La vista non copia alcun dato dalla tabella originale, quindi è buona sia dal punto di vista della memoria che da quello delle prestazioni. Nota tuttavia che non puoi aggiornare / inserire in una vista, solo nella tabella di origine, ma se lo desideri davvero, credo che tu possa reindirizzare gli inserimenti e gli aggiornamenti alla tabella di origine utilizzando le regole (potrei sbagliarmi su quest'ultimo punto come Non l'ho mai provato io stesso).

Modifica: sembra che se la query coinvolge indici concorrenti, il motore di pianificazione a volte potrebbe non utilizzare affatto l'indice di espressione. La scelta sembra dipendere dai dati.

Un modo per farlo è con un trigger!

CREATE TABLE computed(
    one SERIAL,
    two INT NOT NULL
);

CREATE OR REPLACE FUNCTION computed_two_trg()
RETURNS trigger
LANGUAGE plpgsql
SECURITY DEFINER
AS $BODY$
BEGIN
    NEW.two = NEW.one * 2;

    RETURN NEW;
END
$BODY$;

CREATE TRIGGER computed_500
BEFORE INSERT OR UPDATE
ON computed
FOR EACH ROW
EXECUTE PROCEDURE computed_two_trg();

Il trigger viene attivato prima che la riga venga aggiornata o inserita. Cambia il campo che vogliamo calcolare del NEWrecord e quindi restituisce quel record.

PostgreSQL 12 supporta le colonne generate:

PostgreSQL 12 Beta 1 rilasciato!

Colonne generate

PostgreSQL 12 consente la creazione di colonne generate che calcolano i propri valori con un'espressione utilizzando il contenuto di altre colonne. Questa funzione fornisce colonne generate archiviate, che vengono calcolate su inserimenti e aggiornamenti e vengono salvate su disco. Le colonne generate virtuali, che vengono calcolate solo quando una colonna viene letta come parte di una query, non sono ancora implementate.

Colonne generate

Una colonna generata è una colonna speciale che viene sempre calcolata da altre colonne. Quindi, è per le colonne ciò che una vista è per le tabelle.

CREATE TABLE people (
    ...,
    height_cm numeric,
    height_in numeric GENERATED ALWAYS AS (height_cm * 2.54) STORED
);

db <> fiddle demo

Beh, non sono sicuro che questo sia ciò che intendi, ma Posgres normalmente supporta la sintassi ETL "fittizia". Ho creato una colonna vuota nella tabella e quindi ho dovuto riempirla con record calcolati in base ai valori nella riga.

UPDATE table01
SET column03 = column01*column02; /*e.g. for multiplication of 2 values*/

1. È così fittizio che sospetto che non sia quello che stai cercando.
2. Ovviamente non è dinamico, lo esegui una volta. Ma nessun ostacolo per farlo scattare.

Ho un codice che funziona e utilizzo il termine calcolato, non sono su postgresSQL puro anche se giriamo su PADB

ecco come viene utilizzato

create table some_table as
    select  category, 
            txn_type,
            indiv_id, 
            accum_trip_flag,
            max(first_true_origin) as true_origin,
            max(first_true_dest ) as true_destination,
            max(id) as id,
            count(id) as tkts_cnt,
            (case when calculated tkts_cnt=1 then 1 else 0 end) as one_way
    from some_rando_table
    group by 1,2,3,4    ;

Una soluzione leggera con vincolo Check:

CREATE TABLE example (
    discriminator INTEGER DEFAULT 0 NOT NULL CHECK (discriminator = 0)
);