Unità Funzionali

Introduzione

Esistono due scuole di pensiero sull'esecuzione di calcoli nel database:le persone che pensano che sia fantastico e le persone che si sbagliano. Questo non vuol dire che il mondo delle funzioni, delle procedure memorizzate, delle colonne generate o calcolate e dei trigger sia tutto rose e fiori! Questi strumenti sono tutt'altro che infallibili e implementazioni sconsiderate possono funzionare male, traumatizzare i loro manutentori e altro, il che spiega in qualche modo l'esistenza di controversie.

Ma i database sono, per definizione, molto bravi a elaborare e manipolare le informazioni e la maggior parte di essi mette a disposizione degli utenti lo stesso controllo e potere (SQLite e MS Access in misura minore). I programmi di elaborazione dati esterni iniziano in secondo piano, dovendo estrarre informazioni dal database, spesso attraverso una rete, prima che possano fare qualsiasi cosa. E mentre i programmi di database possono trarre pieno vantaggio dalle operazioni sui set nativi, dall'indicizzazione, dalle tabelle temporanee e da altri frutti di mezzo secolo di evoluzione del database, i programmi esterni di qualsiasi complessità tendono a coinvolgere un certo livello di reinvenzione della ruota. Allora perché non mettere in funzione il database?

Ecco perché potresti non vuoi programmare il tuo database!

La funzionalità del database tende a diventare invisibile, in particolare i trigger. Questa debolezza si adatta approssimativamente alle dimensioni dei team e/o delle applicazioni che interagiscono con il database, poiché meno persone ricordano o sono a conoscenza della programmazione all'interno del database. La documentazione aiuta, ma solo così tanto.
SQL è un linguaggio creato appositamente per la manipolazione di set di dati. Non è particolarmente efficace nelle cose che non manipolano i set di dati, ed è tanto meno efficace quanto più complicate diventano quelle altre cose.
Le capacità RDBMS e i dialetti SQL differiscono. Le colonne generate semplici sono ampiamente supportate, ma il porting di una logica di database più complessa in altri archivi richiede tempo e fatica come minimo.
Gli aggiornamenti dello schema del database sono generalmente più complessi degli aggiornamenti delle applicazioni. È meglio mantenere la logica in rapida evoluzione altrove, anche se può valere la pena dare un'altra occhiata una volta che le cose si saranno stabilizzate.
La gestione dei programmi di database non è così semplice come si potrebbe sperare. Molti strumenti di migrazione dello schema fanno poco o nulla per l'organizzazione, portando a differenze tentacolari e revisioni del codice onerose (i grafici delle dipendenze di Sqitch e la rielaborazione dei singoli oggetti ne fanno un'eccezione notevole e la migrazione cerca di eludere completamente il problema). Nei test, framework come pgTAP e utPLSQL migliorano i test di integrazione black-box, ma rappresentano anche un ulteriore supporto e impegno di manutenzione.
Con una base di codice esterna consolidata, qualsiasi cambiamento strutturale tende a essere sia impegnativo che rischioso.

D'altra parte, per le attività a cui è adatto, SQL offre velocità, concisione, durata e l'opportunità di "canonizzare" i flussi di lavoro automatizzati. La modellazione dei dati è più che fissare entità come insetti su cartone e la distinzione tra dati in movimento e dati inattivi è complicata. Il riposo è davvero un movimento più lento con un grado più fine; le informazioni fluiscono sempre da qui a lì e la programmabilità del database è un potente strumento per gestire e dirigere tali flussi.

Alcuni motori di database dividono la differenza tra SQL e altri linguaggi di programmazione adattando anche quegli altri linguaggi di programmazione. SQL Server supporta funzioni scritte in qualsiasi linguaggio .NET Framework; Oracle dispone di procedure memorizzate Java; PostgreSQL consente estensioni con C ed è programmabile dall'utente in Python, Perl e Tcl, con plug-in che aggiungono script di shell, R, JavaScript e altro. A completare i soliti sospetti, è SQL o niente per MySQL e MariaDB, MS Access è solo programmabile in VBA e SQLite non è affatto programmabile dall'utente.

L'uso di linguaggi non SQL è un'opzione se SQL è inadeguato per alcune attività o se si desidera riutilizzare altro codice, ma non risolverà gli altri problemi che rendono la programmazione del database un'arma a molti tagli. Se non altro, il ricorso a questi complica ulteriormente la distribuzione e l'interoperabilità. Scrittore di avvertenza:fai attenzione allo scrittore.

Funzioni e procedure

Un blocco denominato di SQL gestito ed eseguito nel database sembra non essere troppo diverso da un altro, ma la maggior parte degli RDBMS ha funzioni distinte e procedure archiviate per decenni.

Come per altri aspetti dell'implementazione dello standard SQL, i dettagli esatti variano leggermente da RDBMS a RDBMS. In generale:

Le funzioni non possono controllare le transazioni.
Le funzioni restituiscono valori; le procedure possono modificare i parametri designati OUT o INOUT che può quindi essere letto nel contesto chiamante, ma non restituire mai un risultato (ad eccezione di SQL Server).
Le funzioni vengono invocate all'interno delle istruzioni SQL per eseguire alcune operazioni sui record recuperati o archiviati, mentre le procedure sono autonome.

Più specificamente, MySQL non consente la ricorsione e alcune istruzioni SQL aggiuntive nelle funzioni. SQL Server impedisce alle funzioni di modificare i dati, eseguire SQL dinamico e gestire gli errori. PostgreSQL non ha separato le procedure archiviate dalle funzioni fino al 2017 con la versione 11, quindi le funzioni di Postgres possono fare quasi tutto ciò che le procedure possono fare, escludendo il controllo delle transazioni.

Allora, quale usare quando? Le funzioni sono più adatte alla logica che applica record per record man mano che i dati vengono archiviati e recuperati. I flussi di lavoro più complessi che vengono richiamati da soli e spostano i dati all'interno sono migliori come procedure.

Default e generazione

Anche i calcoli semplici possono creare problemi se vengono eseguiti abbastanza spesso o se esistono più implementazioni concorrenti. Le operazioni sui valori in un'unica riga - pensa alla conversione tra unità metriche e imperiali, moltiplicando una tariffa per le ore lavorate per i totali parziali delle fatture, calcolando l'area di un poligono geografico - possono essere dichiarate in una definizione di tabella per affrontare l'uno o l'altro problema :

CREATE TABLE pythag (  a INT NOT NULL,  b INT NOT NULL,  c DOUBLE PRECISION NOT NULL    GENERATED ALWAYS AS (sqrt(pow(a, 2) + pow(b, 2)))    STORED);

La maggior parte degli RDBMS offre una scelta tra colonne generate "memorizzate" e "virtuali". Nel primo caso, il valore viene calcolato e memorizzato al momento dell'inserimento o dell'aggiornamento della riga. Questa è l'unica opzione con PostgreSQL, a partire dalla versione 12, e MS Access. Le colonne generate virtuali vengono calcolate quando interrogate come nelle viste, quindi non occupano spazio ma verranno ricalcolate più spesso. Entrambi i tipi sono strettamente vincolati:i valori non possono dipendere da informazioni al di fuori della riga a cui appartengono, non possono essere aggiornati e i singoli RDBMS possono avere limitazioni ancora più specifiche. PostgreSQL, ad esempio, vieta il partizionamento di una tabella su una colonna generata.

Le colonne generate sono uno strumento specializzato. Più spesso, tutto ciò che serve è un valore predefinito nel caso in cui un valore non sia fornito all'inserimento. Funziona come now() vengono visualizzati frequentemente come valori predefiniti delle colonne, ma la maggior parte dei database consente funzioni personalizzate e integrate (tranne MySQL, dove solo current_timestamp potrebbe essere un valore predefinito).

Prendiamo l'esempio piuttosto secco ma semplice di un numero di lotto nel formato YYYYXXX, dove le prime quattro cifre rappresentano l'anno in corso e le ultime tre un contatore incrementale:il primo lotto prodotto quest'anno è 2020001, il secondo 2020002 e così via . Non esiste un tipo predefinito o una funzione incorporata che generi un valore come questo, ma una funzione definita dall'utente può numerare ogni lotto man mano che viene creato :

CREATE SEQUENCE lot_counter;CREATE OR REPLACE FUNCTION next_lot_number () RETURNS TEXT AS $$BEGIN  RETURN date_part('year', now())::TEXT ||    lpad(nextval('lot_counter'::REGCLASS)::TEXT, 2, '0');END;$$LANGUAGE plpgsql;CREATE TABLE lots (  lot_number TEXT NOT NULL DEFAULT next_lot_number () PRIMARY KEY,  current_quantity INT NOT NULL DEFAULT 0,  target_quantity INT NOT NULL,  created_at TIMESTAMPTZ NOT NULL DEFAULT now(),  completed_at TIMESTAMPTZ,  CHECK (target_quantity > 0));

Riferimento ai dati nelle funzioni

L'approccio sequenziale di cui sopra ha un punto debole importante (e almeno uno meno importante ):arriva il nuovo anno, lot_counter avrà ancora lo stesso valore che aveva il 31 dicembre. C'è più di un modo per tenere traccia di quanti lotti sono stati creati in un anno, però, e interrogando lots stesso il next_lot_number la funzione può garantire un valore corretto dopo il rollover dell'anno.

CREATE OR REPLACE FUNCTION next_lot_number () RETURNS TEXT AS $$BEGIN  RETURN (    SELECT date_part('year', now())::TEXT || lpad((count(*) + 1)::TEXT, 2, '0')    FROM lots    WHERE date_part('year', created_at) = date_part('year', now())  );END;$$LANGUAGE plpgsql;ALTER TABLE lots  ALTER COLUMN lot_number SET DEFAULT next_lot_number();

Flussi di lavoro

Anche una funzione a istruzione singola ha un vantaggio cruciale rispetto al codice esterno:l'esecuzione non lascia mai la sicurezza delle garanzie ACID del database. Confronta next_lot_number sopra alle possibilità di un'applicazione client o anche di un processo manuale, eseguendo un'istruzione SQL per contare il numero di lotti di quest'anno fino ad oggi seguito da un secondo che inserisce il nuovo lotto. Se gli ordini vengono effettuati abbastanza velocemente, il numero di lotti potrebbe cambiare sotto di te tra il conteggio e l'inserimento.

I programmi memorizzati con più istruzioni aprono un immenso spazio di possibilità, poiché SQL include tutti gli strumenti necessari per scrivere codice procedurale, dalla gestione delle eccezioni ai punti di salvataggio (è persino Turing completo di funzioni di finestra ed espressioni di tabelle comuni!). Interi flussi di lavoro di elaborazione dei dati possono essere eseguiti nel database, riducendo al minimo l'esposizione ad altre aree del sistema ed eliminando i lunghi viaggi di andata e ritorno tra il database e altri domini.

Gran parte dell'architettura software in generale riguarda la gestione e l'isolamento della complessità, impedendo che si diffonda oltre i confini tra i sottosistemi. Se un flusso di lavoro più o meno complicato prevede l'inserimento di dati in un back-end, uno script o un lavoro cron dell'applicazione, la digestione e l'aggiunta ad esso e la memorizzazione del risultato, è il momento di chiedersi cosa richiede davvero di avventurarsi al di fuori del database.

Come accennato in precedenza, questa è un'area in cui emergono le differenze tra le versioni RDBMS e i dialetti SQL. Una funzione o una procedura sviluppata per un database probabilmente non verrà eseguita su un altro senza modifiche, indipendentemente dal fatto che stia sostituendo TOP di SQL ServerSQL Server per un LIMIT standard clausola o rielaborando completamente il modo in cui lo stato temporaneo viene archiviato in una migrazione aziendale da Oracle a PostgreSQL. Canonizzare i flussi di lavoro in SQL ti impegna anche sulla piattaforma e sul dialetto attuali in modo più completo di qualsiasi altra scelta tu possa fare.

Calcoli nelle query

Finora abbiamo esaminato l'utilizzo delle funzioni per archiviare e modificare i dati, sia associati alle definizioni di tabelle che alla gestione di flussi di lavoro multi-tabella. In un certo senso, questo è l'uso più potente a cui possono essere destinati, ma anche le funzioni hanno un posto nel recupero dei dati. Molti strumenti che potresti già utilizzare nelle tue query sono implementati come funzioni, da built-in standard come count a estensioni come jsonb_build_object di Postgres , ST_SnapToGrid di PostGIS , e altro ancora. Naturalmente, dal momento che sono più strettamente integrati con il database stesso, sono scritti principalmente in linguaggi diversi da SQL (es. C nel caso di PostgreSQL e PostGIS).

Se ti ritrovi spesso (o pensi di poterti ritrovare) a dover recuperare dati e quindi eseguire alcune operazioni su ogni record prima che sia realmente pronto, considera invece di trasformarli mentre esci dal database! Proiezione di un certo numero di giorni lavorativi da una data? Generazione di una differenza tra due JSONB campi? Praticamente qualsiasi calcolo che dipenda solo dalle informazioni che stai interrogando può essere eseguito in SQL. E ciò che viene fatto nel database, purché vi si acceda in modo coerente, è canonico per quanto riguarda qualsiasi cosa costruita sul database.

Va detto:se stai lavorando con un back-end di un'applicazione, il suo toolkit di accesso ai dati può limitare il chilometraggio che ottieni aumentando i risultati delle query con le funzioni. La maggior parte di tali librerie può eseguire SQL arbitrario, ma quelle che generano istruzioni SQL comuni basate su classi modello possono o meno consentire la personalizzazione della query SELECT liste. Le colonne o le viste generate possono essere una risposta qui.

Trigger e conseguenze

Funzioni e procedure sono abbastanza controverse tra i progettisti e gli utenti di database, ma le cose veramente decollare con i grilletti. Un trigger definisce un'azione automatica, solitamente una procedura (SQLite consente solo una singola istruzione), da eseguire prima, dopo o al posto di un'altra azione.

L'azione di avvio è generalmente un inserimento, un aggiornamento o un'eliminazione in una tabella e la procedura di trigger può essere generalmente impostata per essere eseguita per ciascun record o per l'istruzione nel suo insieme. SQL Server consente anche trigger su viste aggiornabili, principalmente come un modo per applicare misure di sicurezza più dettagliate; ed esso, PostgreSQL e Oracle offrono tutti una qualche forma di evento o DDL trigger che può reagire ai cambiamenti nella struttura del database.

Un uso comune a basso rischio per i trigger è un vincolo extra potente che impedisce l'archiviazione di dati non validi. In tutti i principali database relazionali, solo chiavi primarie ed esterne e UNIQUE i vincoli possono valutare le informazioni al di fuori del record del candidato. Non è possibile dichiarare in una definizione di tabella che, ad esempio, possono essere creati solo due lotti in un mese -- e la soluzione più semplice di database e codice è vulnerabile a una race condition simile all'approccio count-then-set a lot_number sopra. Per applicare qualsiasi altro vincolo che coinvolga l'intera tabella, o altre tabelle, è necessario un trigger per vedere al di fuori dell'ambito del record:

CREATE FUNCTION enforce_monthly_lot_limit () RETURNS TRIGGERAS $$DECLARE current_count BIGINT;BEGIN  SELECT count(*) INTO current_count  FROM lots  WHERE date_trunc('month', created_at) = date_trunc('month', NEW.created_at);  IF current_count >= 2 THEN    RAISE EXCEPTION 'Two lots already created this month';  END IF;  RETURN NEW;END;$$LANGUAGE plpgsql;CREATE TRIGGER monthly_lot_limitBEFORE INSERT ON lotsFOR EACH ROWEXECUTE PROCEDURE enforce_monthly_lot_limit();

Una volta avviata l'esecuzione di DML e usando il controllo del flusso, è un salto salta e salta per dare il via a sequenze di passaggi molto più complicate ed espandere l'ambito per includere ancora altre tabelle. Forse l'inserimento di un record in lots di per sé potrebbe essere l'operazione finale di un trigger avviato da un inserimento in orders , senza alcun utente umano o back-end dell'applicazione autorizzato a scrivere su lots direttamente. O come items vengono aggiunti a un lotto, un trigger potrebbe gestire l'aggiornamento di current_quantity e avvia un altro processo quando raggiunge il target_quantity .

Trigger e funzioni possono essere eseguiti al livello di accesso del loro definitore (in PostgreSQL, un SECURITY DEFINER dichiarazione accanto a LANGUAGE di una funzione ), che offre agli utenti altrimenti limitati il potere di avviare processi di più ampia portata e rende la convalida e il test di tali processi ancora più importante.

Lo stack di chiamate trigger-action-trigger-action può diventare arbitrariamente lungo, sebbene la vera ricorsione sotto forma di modifica delle stesse tabelle o record più volte in qualsiasi flusso di questo tipo sia illegale su alcune piattaforme e più in generale una cattiva idea in quasi tutte le circostanze. La nidificazione dei trigger supera rapidamente la nostra capacità di comprenderne l'estensione e gli effetti. I database che fanno un uso massiccio di trigger nidificati iniziano a spostarsi dal regno del complicato a quello del complesso, diventando difficili o impossibili da analizzare, eseguire il debug e prevedere.

Programmabilità pratica

I calcoli nel database non sono solo più veloci e più concisi:eliminano l'ambiguità e stabiliscono standard. Gli esempi precedenti liberano gli utenti del database dal dover calcolare i numeri di lotto da soli o dalla preoccupazione di creare accidentalmente più lotti di quelli che possono gestire. Gli sviluppatori di applicazioni, in particolare, sono stati spesso addestrati a pensare ai database come a uno "spazio di archiviazione stupido", fornendo solo struttura e persistenza, e possono quindi trovarsi - o peggio, non rendersi conto che lo sono - ad articolare goffamente al di fuori del database ciò che potrebbero fare in modo più efficace in SQL.

La programmabilità è una caratteristica ingiustamente trascurata dei database relazionali. Esistono ragioni per evitarlo e altre per limitarne l'uso, ma funzioni, procedure e trigger sono tutti strumenti potenti per limitare la complessità che il tuo modello di dati impone ai sistemi in cui è integrato.