Dichiara una variabile SQL: sintassi e best practice 2026

La maggior parte dei consigli su come dichiarare una variabile SQL parte troppo in basso nella pila. Tratta le variabili come una funzionalità di comodità, un piccolo dettaglio di sintassi che si apprende strada facendo mentre si scrive una stored procedure.

Questa visione è incompleta.

Quando i team dichiarano una variabile SQL, stanno facendo molto più che riservare memoria per un valore. Stanno definendo tipo, scope, stato atteso e confini decisionali all'interno di un'operazione di database. Negli ambienti regolamentati, questo conta perché i sistemi affidabili dipendono da controlli espliciti. Uno script che nasconde assunzioni nella concatenazione di stringhe, nelle conversioni implicite o in valori con scope poco definito è più difficile da testare, più difficile da revisionare e più difficile da difendere durante un audit.

In SQL Server, questo punto è particolarmente chiaro. Microsoft documenta DECLARE @local_variable come il meccanismo T-SQL standard per creare una variabile locale all'interno di un batch o di una stored procedure, con la variabile inizializzata a NULL a meno che non venga fornito un valore al momento della dichiarazione, e con scope limitato al batch o alla procedura in cui esiste (Microsoft T-SQL variable declaration reference). Non si tratta solo di una curiosità sul linguaggio. Significa che il motore ti offre un'unità esplicita di stato locale con regole chiare di durata e di datatype.

Per i team operativi, questo rende la dichiarazione delle variabili parte della governance, non solo della programmazione. Una variabile dichiarata mostra ai revisori cosa il codice si aspetta, da dove proviene il valore, per quanto tempo rimane valido e quale parte della procedura ne è responsabile. Sono le stesse preoccupazioni che emergono nel controllo degli accessi, nella gestione delle modifiche e nella raccolta delle evidenze. Un buon SQL non separa correttezza tecnica e responsabilità. Le costruisce entrambe nello script.

Introduzione

La scorciatoia più diffusa dice che le variabili servono soprattutto a rendere SQL più flessibile. È vero, ma perde il punto più importante. La flessibilità senza controllo di solito produce script che si comportano in modo diverso sotto pressione, soprattutto quando crescono fino a diventare procedure operative usate da più team.

Una variabile ben dichiarata crea un confine. Dice al motore di database, e a chiunque revisioni il codice, che un valore ha una forma definita e una durata limitata. Ecco perché le variabili contano nelle stored procedure, negli script di correzione dati e nelle attività di manutenzione governate. Trasformano le assunzioni in artefatti che puoi ispezionare.

La comodità è il modello mentale sbagliato

Se l'unica domanda è “come faccio a memorizzare un valore temporaneo?”, quasi ogni scorciatoia sembra accettabile. I team iniziano ad assegnare in modo approssimativo, a riutilizzare nomi o a passare valori tramite dynamic SQL senza pensare allo scope. Lo script può ancora funzionare, ma diventa difficile da comprendere.

Regola pratica: tratta ogni dichiarazione di variabile come un'istruzione di controllo, non come un'istruzione di comodità.

Questa mentalità cambia le scelte di progettazione. Smetti di chiederti se una variabile è necessaria per brevità e inizi a chiederti se migliora la prevedibilità. In molti ambienti di produzione, questa è la differenza tra uno script che può essere approvato con fiducia e uno che richiede supervisione manuale ogni volta che viene eseguito.

La prevedibilità conta più della brevità

Un SQL breve non è automaticamente un buon SQL. Anzi, il codice compatto spesso nasconde decisioni importanti che dovrebbero essere rese esplicite. Dichiarare le variabili obbliga a portare queste decisioni alla luce.

Un revisore può ispezionare:

• Intenzione del datatype. Se lo script si aspetta un intero, una data, un valore testuale o qualcosa di più specifico.
• Stato iniziale. Se il codice parte da NULL, da una baseline fissa o da un valore fornito dal chiamante.
• Scope operativo. Se il valore deve esistere solo all'interno di un singolo batch o di una procedura.

Ecco perché la dichiarazione delle variabili rientra nelle conversazioni su auditabilità e resilienza. È uno dei mattoni più piccoli in SQL, ma supporta alcune delle qualità più grandi che un sistema dati richiede: tracciabilità, testabilità ed esecuzione ripetibile.

Perché le variabili sono un controllo fondamentale

Una dichiarazione di variabile è spesso la prima riga di una procedura che rende la procedura governabile. Una volta che un valore è nominato, tipizzato e delimitato, il resto della logica può lavorare su qualcosa di esplicito invece che implicito.

Il typing è un controllo inline

Quando dichiari una variabile con un datatype specifico, crei un controllo locale nel punto in cui i dati entrano nella logica della procedura. Questo conta perché molti errori non iniziano con SQL palesemente sbagliato. Iniziano con valori che sono tecnicamente accettati ma semanticamente errati per il compito.

Una data rappresentata come testo libero, per esempio, lascia troppo spazio all'ambiguità. Una variabile data tipizzata riduce quello spazio. Lo stesso vale per contatori, identificatori, flag di stato e valori monetari. La dichiarazione stessa diventa una dichiarazione di intenti.

Questo è utile nella code review perché sposta la validazione a sinistra. Invece di fidarsi della logica a valle per intercettare stati errati, lo script definisce le proprie aspettative fin dall'inizio.

Lo scope limita il comportamento accidentale

Una variabile locale è anche un controllo di scope. In T-SQL, le variabili locali esistono all'interno del batch o della stored procedure in cui vengono dichiarate, il che è uno dei motivi per cui DECLARE è un meccanismo base per un comportamento riproducibile nel codice procedurale (Microsoft documentation on local variable scope and declaration).

Lo scope è una questione di governance tanto quanto una questione di coding. Un valore che vive troppo a lungo può essere riutilizzato per errore. Un valore che trapela oltre i confini di esecuzione può creare assunzioni non visibili nella definizione della procedura. Mantenere le variabili locali riduce le dipendenze nascoste.

Uno script diventa più facile da fidare quando ogni valore importante ha un proprietario visibile e una durata chiara.

È lo stesso principio usato nella progettazione degli accessi. I team concedono privilegi in modo ristretto perché autorizzazioni ampie creano incertezza. Lo scope delle variabili funziona in modo simile. Uno scope ristretto crea fiducia.

La logica esplicita è più facile da testare

Le variabili rendono anche ispezionabili le decisioni procedurali. Se uno script decide se aggiornare i record, deviare verso la gestione delle eccezioni o interrompere del tutto l'elaborazione, le variabili dichiarate danno a quelle decisioni nomi e stati che possono essere testati direttamente.

Considera cosa succede durante la revisione:

Questo non significa che ogni espressione abbia bisogno di una propria variabile. Significa che i valori critici dovrebbero essere abbastanza espliciti da poter essere ispezionati da un altro engineer, da un auditor o da un responsabile operativo senza dover fare reverse engineering dell'intera procedura.

La governance inizia nel codice

Politiche e documenti di processo sono importanti, ma il controllo procedurale spesso inizia nello script stesso. Una variabile dichiarata documenta input attesi, stato locale e flusso previsto in una forma che il motore di database impone.

Ecco perché la dichiarazione delle variabili appartiene alla buona database engineering. È uno dei modi più semplici per rendere la logica operativa visibile, delimitata e verificabile.

Dichiarare le variabili nei principali dialetti SQL

La dichiarazione delle variabili mostra come ogni prodotto database si aspetta che tu controlli lo stato. Questo conta più della sintassi. Negli ambienti regolamentati o con forte revisione, il dialetto determina dove può vivere lo stato, quanto è visibile ai revisori e con quale facilità uno script può essere riprodotto sotto change control.

SQL Server e T-SQL

SQL Server consente variabili locali in batch ad hoc, script e stored procedure. Le variabili usano il prefisso @, che le rende facili da distinguere da colonne, parametri e letterali durante la revisione.

DECLARE @CustomerId INT;
DECLARE @RunDate DATE = '2026-01-15';
DECLARE @Status NVARCHAR(20) = N'Pending';

SET @CustomerId = 42;
SET @Status = N'Approved';

Questa flessibilità è utile, ma comporta responsabilità. I team spesso iniziano con script operativi rapidi in T-SQL, poi continuano ad ampliarlos fino a quando quegli script diventano parte di un processo di produzione. A quel punto, dichiarazione chiara e assegnazione esplicita smettono di essere preferenze di stile e iniziano a influire sull'auditabilità.

SQL Server offre anche più di un modo per assegnare valori. In pratica, SET è più facile da revisionare perché rende esplicita l'assegnazione di un singolo valore. L'assegnazione con SELECT può essere concisa, ma può anche nascondere assunzioni sul numero di righe se la query non è strettamente controllata.

Oracle e PL SQL

Oracle colloca le variabili all'interno di un blocco PL/SQL, di una procedura o di una funzione. L'area di dichiarazione appare prima di BEGIN, il che costringe a definire in anticipo lo stato locale.

DECLARE
  v_customer_id NUMBER := 42;
  v_run_date DATE := DATE '2026-01-15';
  v_status VARCHAR2(20) := 'Pending';
BEGIN
  v_status := 'Approved';
END;
/

Questa struttura funziona bene in ambienti in cui le procedure passano attraverso una revisione formale. Un engineer può ispezionare prima la sezione di dichiarazione, capire lo stato locale previsto e poi valutare la logica eseguibile con meno sorprese.

La convenzione comune di naming v_ non è richiesta da Oracle. Sopravvive perché riduce l'ambiguità nei codebase reali, soprattutto dove colonne di tabella, parametri e variabili locali altrimenti competerebbero per gli stessi nomi.

Stored procedure MySQL

MySQL supporta variabili locali all'interno di stored procedure e unità di programma simili. Vengono dichiarate all'interno di BEGIN ... END, di solito prima di altre istruzioni procedurali.

DELIMITER //

CREATE PROCEDURE ProcessCustomer(IN p_customer_id INT)
BEGIN
  DECLARE v_run_date DATE DEFAULT '2026-01-15';
  DECLARE v_status VARCHAR(20) DEFAULT 'Pending';
  DECLARE v_review_needed BOOLEAN DEFAULT FALSE;

  SET v_status = 'Approved';
END //

DELIMITER ;

La principale preoccupazione operativa in MySQL non è il keyword DECLARE in sé. È la differenza tra variabili locali di procedura e variabili definite dall'utente a livello di sessione. Le variabili locali seguono in genere convenzioni come v_. Le variabili di sessione usano @. Queste due forme non hanno la stessa finalità, e mescolarle negli script di manutenzione crea confusione su scope, durata e su chi possa rieseguire il codice in sicurezza.

Questa distinzione conta durante la risposta agli incidenti. Se uno script si basa su variabili di sessione lasciate da un passaggio precedente, eseguirne il replay più tardi può produrre un esito diverso.

PostgreSQL e PL pgSQL

PostgreSQL mantiene le variabili procedurali all'interno di funzioni PL/pgSQL, procedure o blocchi anonimi DO. Le normali istruzioni SQL non usano variabili locali nello stesso modo diretto che molti engineer di SQL Server si aspettano.

DO $$
DECLARE
  customer_id INTEGER := 42;
  run_date DATE := DATE '2026-01-15';
  status TEXT := 'Pending';
BEGIN
  status := 'Approved';
END $$;

Questa separazione è utile. Disegna un confine più pulito tra SQL set-based e logica di controllo procedurale. Per la governance, questo significa che i revisori possono capire se una modifica riguarda la logica di query, il flusso di esecuzione o entrambi.

Cambia anche le scelte di progettazione. In PostgreSQL, un engineer può scegliere una funzione, un blocco DO o una CTE a seconda che il requisito sia stato temporaneo, logica riutilizzabile o una trasformazione di query a passaggio unico.

Un rapido confronto

La regola pratica è semplice. Non trattare la dichiarazione delle variabili come portabile solo perché il keyword sembra familiare. Ogni dialetto definisce un confine di controllo diverso, e quel confine influisce sulla manutenibilità, sullo sforzo di revisione e sulla prevedibilità di esecuzione.

Uso pratico negli script e nelle stored procedure

Il valore delle variabili diventa evidente quando uno script smette di essere una singola query e inizia a comportarsi come un'unità operativa. A quel punto, le variabili conservano lo stato, catturano le decisioni e collegano un'azione alla successiva.

Guidare il flusso di controllo

Una stored procedure spesso deve fare branching in base alle condizioni correnti. Le variabili rendono queste condizioni visibili e riutilizzabili invece di incorporarle in espressioni ripetute.

DECLARE @CustomerId INT = 42;
DECLARE @CustomerStatus NVARCHAR(20);
DECLARE @IsApproved BIT = 0;

SELECT @CustomerStatus = Status
FROM dbo.Customers
WHERE CustomerId = @CustomerId;

IF @CustomerStatus = N'Active'
BEGIN
    SET @IsApproved = 1;
END
ELSE
BEGIN
    SET @IsApproved = 0;
END

Questo pattern conta perché la procedura espone ora uno stato decisionale. Un revisore può verificare da dove proviene @CustomerStatus e come è stato determinato @IsApproved. È molto più verificabile rispetto a spargere la stessa condizione in più istruzioni.

Per le organizzazioni che gestiscono accessi privilegiati e operazioni controllate, la stessa disciplina compare altrove. Una transizione di stato verificabile è molto più sicura di una nascosta, ed è per questo che i workflow di accesso dipendono da confini espliciti e ownership, come spiegato in questa guide to privileged access management.

Prima di guardare a un altro pattern di utilizzo, questo walkthrough offre un riepilogo visivo utile:

Catturare output e stato intermedio

Le variabili sono utili anche quando un passaggio produce un valore da cui dipendono i passaggi successivi. Questo include identificatori generati durante insert, output di procedure o valori recuperati per la validazione prima di una modifica.

DECLARE @OrderId INT;
DECLARE @NewStatus NVARCHAR(20) = N'Processed';

SELECT @OrderId = OrderId
FROM dbo.Orders
WHERE ExternalReference = N'PO-7781';

IF @OrderId IS NOT NULL
BEGIN
    UPDATE dbo.Orders
    SET Status = @NewStatus
    WHERE OrderId = @OrderId;
END

Qui la variabile funge da checkpoint. Lo script non passa direttamente dal lookup all'update senza nominare la dipendenza. Questo rende più facile il testing e riduce il rischio di modifiche involontarie.

Gestire loop e ripetizioni controllate

Le variabili diventano essenziali quando una procedura deve elaborare dati in batch controllati o riprovare una piccola unità di lavoro. Gestiscono contatori, flag e condizioni di arresto.

• I contatori aiutano le procedure a iterare in modo deterministico attraverso una sequenza nota.
• I flag permettono di mantenere visibili le condizioni di eccezione dopo che un controllo è avvenuto.
• I valori di confine come date o stati mantengono esplicito lo scope di elaborazione.

Se una procedura ripete il lavoro, lo stato che controlla quella ripetizione dovrebbe essere visibile nelle variabili, non nascosto dentro un frammento di query.

Questo conta per la resilienza. Durante la revisione di un incidente, i team devono capire perché una procedura ha continuato, si è fermata o ha ritentato. Le variabili lasciano questa logica in piena vista.

Costruire logica dinamica in modo sicuro

Alcune procedure richiedono dynamic SQL. Il pattern sicuro è usare le variabili come parametri o come input chiaramente separati per un'esecuzione controllata, non come scuse per assemblare istruzioni arbitrarie tramite concatenazione non verificata.

Le variabili aiutano perché separano i dati dalla struttura del comando. Non è solo un codice più pulito. È una protezione di base contro fallimenti di sicurezza e di revisione evitabili.

Errori comuni e come evitarli

La gestione delle variabili fallisce spesso in modi ordinari. Gli errori non sono esotici. Di solito derivano da scope poco chiaro, assunzioni su NULL o scelte imprudenti di datatype.

Gli errori di scope nel dynamic SQL

Uno degli errori T-SQL più comuni appare quando i team dichiarano una variabile locale fuori da un'istruzione dynamic SQL e si aspettano che sia visibile all'interno di quel batch dinamico. In pratica, il dynamic SQL viene eseguito in un batch separato, quindi le variabili locali dichiarate all'esterno non sono disponibili all'interno. La soluzione è passare i parametri in modo esplicito invece di affidarsi a variabili di outer scope (discussion of T-SQL dynamic SQL batch scope).

Il sintomo è semplice. L'istruzione dinamica fallisce, oppure si comporta come se la variabile non esistesse. La causa è altrettanto semplice. La variabile appartiene a uno scope di esecuzione, mentre il batch dinamico ne usa un altro.

NULL non è un segnaposto per la certezza

Le variabili che non vengono inizializzate esplicitamente diventano spesso fonte di sottili errori logici. Una condizione può sembrare completa, ma un confronto con NULL non si comporta come un revisore si aspetta se lo script tratta NULL come se fosse un valore ordinario.

Usa valori iniziali espliciti quando la regola di business lo richiede. Se NULL ha significato, gestiscilo deliberatamente nella logica condizionale. Se non ha significato, non permettere allo script di scivolare in quello stato.

Una buona abitudine quotidiana è controllare le dichiarazioni delle variabili come faresti con i contratti di input di un'applicazione. Se un valore può essere sconosciuto, dillo. Se non può esserlo, inizializzalo a uno stato operativo valido.

Le incompatibilità di tipo creano rischio silenzioso

La conversione implicita è comoda fino a quando non lo è più. Un valore può essere convertito automaticamente, troncato o rifiutato a seconda del motore e del contesto. Nell'SQL operativo, questo non è solo un fastidio tecnico. È un problema di tracciabilità, perché le assunzioni dello script non corrispondono più chiaramente al percorso dei dati.

Un modo disciplinato per ridurre questo rischio è mantenere i tipi delle variabili allineati ai valori che rappresentano. Se una variabile rispecchia una colonna, abbina il più possibile il tipo previsto della colonna, nei limiti consentiti dal dialetto.

Per i team che vogliono rafforzare la qualità complessiva del proprio SQL, questa practical guide to SQL queries è utile perché inquadra leggibilità e correttezza come parte della stessa disciplina ingegneristica. Lo stesso principio vale per le evidenze verificabili. Se vuoi che modifiche e decisioni reggano nel tempo, un audit trail with clear best practices dipende da un comportamento di sistema esplicito e intelligibile, non da assunzioni nascoste.

Una buona gestione delle variabili riduce l'ambiguità prima ancora che un audit trail debba spiegare l'esito.

Best practice per performance e sicurezza

Dichiarare una variabile è una decisione di controllo, non una scelta estetica. Nell'SQL di produzione, ogni valore dichiarato influenza il comportamento di uno script, ciò che un revisore può verificare e quanto un team può spiegare con fiducia un esito in seguito.

La sicurezza viene prima con la disciplina dei parametri

Le variabili dovrebbero trasportare dati, non intenti eseguibili. Il pattern più sicuro è associare i valori tramite parametri e mantenere fissa la struttura SQL nel codice.

Questa distinzione è critica, perché un SQL sicuro dipende da una chiara separazione delle responsabilità. La procedura o lo script definisce l'operazione consentita. Gli input forniscono valori all'interno di quell'operazione. Una volta che l'input esterno inizia a modellare il testo dei comandi tramite concatenazione di stringhe, l'auditabilità diminuisce e con essa aumenta il rischio di injection.

La stessa disciplina si vede negli ambienti regolamentati. I team che rendono espliciti i percorsi approvati hanno molta più facilità a dimostrare il design dei controlli e ad applicarlo in modo coerente, il che è al centro di solidi data security and compliance controls.

Le prestazioni richiedono test deliberati

Le variabili possono cambiare il comportamento di esecuzione anche quando il testo SQL sembra pulito. In SQL Server, le variabili locali a volte indeboliscono le stime di cardinalità perché l'ottimizzatore potrebbe non usare i dati dell'histogram nel modo in cui farebbe per un valore letterale. Erik Darling documenta questo comportamento di row estimation e mitigazioni comuni come RECOMPILE nel suo articolo su local variables and query plans.

L'implicazione pratica è semplice. Uno script può essere logicamente corretto, superare la code review e comunque scegliere un piano costoso in condizioni di carico reali.

Testa i predicati guidati da variabili con valori rappresentativi, distribuzioni di parametri realistiche e dati delle dimensioni di produzione. Controlla la forma del piano, le letture, i memory grant e la variabilità di runtime, non solo che la query restituisca le righe corrette. Se una variabile nasconde la selectivity all'ottimizzatore, decidi consapevolmente se riscrivere il predicato, separare i percorsi di codice o accettare il costo della recompilazione per un'esecuzione più prevedibile.

La manutenibilità fa parte della resilienza operativa

Il tuning delle prestazioni e la prevenzione dell'injection ricevono di solito la maggiore attenzione. I guasti quotidiani spesso iniziano da qualcosa di meno eclatante. Una variabile nominata male, un valore dichiarato troppo lontano dal punto in cui viene usato o una variabile riutilizzata che porta due significati in una sola procedura possono rendere un flusso di controllo difficile da auditare e facile da rompere.

Alcune abitudini invecchiano bene:

• Nomina per significato operativo. @ReviewCutoffDate dice più di @d1.
• Limita scope e riuso. Una variabile dovrebbe servire a un solo scopo per un solo tratto di codice.
• Posiziona le dichiarazioni vicino alla logica che governano così i revisori possono seguire le decisioni senza scansionare l'intera procedura.
• Commenta solo dove l'intento non è ovvio. Riserva i commenti alla logica di approvazione, alla gestione delle eccezioni o ai rami guidati dalla policy.

Nei sistemi sottoposti ad audit, la chiarezza fa parte delle performance e fa parte della sicurezza. Il codice che può essere letto, testato e spiegato durante una revisione di solito fallisce in meno modi sorprendenti.