Guida pratica al supporto RegEx nativo in SQL Server 2025
Per decenni, noi professionisti dei dati abbiamo vissuto in un paradosso. SQL Server è sempre stato un titano per la gestione di grandi moli di dati, ma di fronte a una richiesta semplice come “estrai solo i numeri di telefono validi da questa colonna sporca”, ci costringeva a salti mortali per riuscire ad ottenere delle performance adeguate.
Le opzioni erano poche: una giungla di LIKE concatenati, l’uso di funzioni CLR (Common Language Runtime) in C# o, peggio, l’esportazione dei dati per elaborarli esternamente, con linguaggi o strumenti più evoluti per quanto riguarda la gestione della ricerca nelle stringhe.
Con SQL Server 2025, questo incubo è finito. Microsoft ha finalmente introdotto il supporto nativo alle Regular Expressions (RegEx) - basato sulla libreria RE2 di Google - integrate direttamente nel motore T-SQL. In questo articolo vedremo come queste funzioni cambiano radicalmente il nostro modo di scrivere codice.
Una regular expression (o regex), è una sequenza di caratteri che definisce un pattern di ricerca in un testo.
Le Regular Expressions possono tornare utili in diversi casi, in quanto forniscono un modo flessibile ed efficiente per:
- ricerca di pattern nel testo
- validazione dei dati
- trasformazione dei dati
- interrogazioni complesse
Il nuovo arsenale
SQL Server 2025 introduce nuove funzioni che coprono l’intero ciclo di vita della manipolazione del testo.
È il sostituto dopato dell’operatore LIKE. Restituisce un valore booleano se il testo corrisponde al pattern. Uso tipico: Validazione dei dati nei vincoli CHECK o filtri nelle clausole WHERE.
Restituisce il numero di volte che un pattern appare in una stringa. Uso tipico: Analisi della densità di parole chiave o conteggio di occorrenze di caratteri speciali.
Restituisce la posizione (indice) dell’inizio o della fine di una corrispondenza. Uso tipico: Parsing di file di log a posizione variabile.
Permettono rispettivamente di sostituire porzioni di testo identificate dal pattern o di estrarre sottostringhe specifiche. Uso tipico: Data Masking, pulizia di stringhe sporche e normalizzazione.
Restituisce una tabella contenente le porzioni delle stringhe che corrispondono al pattern specificato. Uso tipico: Ricerca di tag all’interno del testo.
Note sulla compatibilità
La REGEXP_LIKE e le funzioni table-valued richiedono il livello di compatibilità 170, le altre funzionano con qualsiasi livello di compatibilità.
Caso studio: pulizia e validazione di un database CRM
Immaginiamo di dover ripulire una tabella clienti dove i dati sono stati inseriti senza alcun controllo per anni.
Scenario A: Validazione delle Email
Prima di SQL Server 2025, validare una mail con LIKE era piuttosto approssimato (es. %@%.%).
In SQL Server 2025:
-- Trovare email che non hanno un formato standard
SELECT companyname, email
FROM Customers
WHERE NOT REGEXP_LIKE(email, '^[A-Za-z0-9._%+-]+@[A-Za-z0-9.-]+\.[A-Za-z]{2,4}$');
Il pattern verifica l’inizio della stringa, la presenza della @, il dominio e un’estensione di almeno due caratteri. Semplice, pulito, performante.
Scenario B: Estrazione dei Numeri di Telefono
Supponiamo che la colonna Note contenga commenti del tipo: “Contattare il sig. Rossi al 333-1234567 dopo le 18”. Vogliamo estrarre solo il numero.
In SQL Server 2025:
SELECT
companyname,
note,
REGEXP_SUBSTR(Note, '\d{3} \d{6}') AS ExtractedPhone
FROM Customers
WHERE REGEXP_LIKE(Note, '\d{3} \d{6}');
Qui stiamo cercando una sequenza di 3 cifre, uno spazio e 6 cifre. Senza RegEx, avremmo dovuto usare una combinazione di CHARINDEX, PATINDEX e SUBSTRING che avrebbe reso il codice poco leggibile. Ovviamente in questo caso nei risultati sono presenti anche i numeri che includono questo pattern (Es. Aberdeen Oil che ha il numero 1224 496055)
Scenario C: Implementazione di controlli sui dati
Supponiamo di voler creare una nuova tabella Customers2 ed effettuare il controllo dei dati che l’utente immette. Possiamo sfruttare la REGEXP_LIKE anche all’interno di un vincolo CHECK per garantire che l’inserimento sia “pulito”:
CREATE TABLE Customers2 (
id INT IDENTITY(1,1) PRIMARY KEY,
companyname VARCHAR(255) NOT NULL,
email VARCHAR(255)
CHECK (REGEXP_LIKE(Email, '^[A-Za-z0-9%+-]+(?:.[A-Za-z0-9%+-]+)@[A-Za-z0-9-]+(?:.[A-Za-z0-9-]+).[A-Za-z]{2,}$')),
phone VARCHAR(50),
country VARCHAR(100),
address VARCHAR(255),
postalcode VARCHAR(20),
region VARCHAR(100),
city VARCHAR(100)
);
Se provo ad inserire una riga con l’indirizzo email palesemente errato, ottengo un errore di violazione del vincolo CHECK:
Performance: perché “nativo” è meglio di “CLR”
Molti DBA in passato hanno implementato le RegEx tramite CLR. Sebbene funzionassero, presentavano due problemi critici:
-
Context Switching: Il processore deve passare dal contesto del motore SQL a quello del .NET Framework, con un costo in termini di CPU.
-
Memory Management: Il CLR ha una gestione della memoria separata che può causare frammentazione.
Le nuove funzioni di SQL Server 2025 sono scritte in C++ nativo all’interno del motore relazionale. Questo significa che il query optimizer può gestire le RegEx come se fossero funzioni scalari standard, beneficiando del Parallelismo e di una migliore gestione del piano di esecuzione.
Errori comuni e come evitarli
Passare alle RegEx richiede un cambio di mentalità. Ecco a cosa prestare attenzione:
-
Case Sensitivity: Di default, SQL Server rispetta la collation del database. Se la tua colonna è CI (Case Insensitive), la RegEx si comporterà di conseguenza, a meno che tu non utilizzi i parametri opzionali della funzione per forzare il comportamento.
-
L’avidità (Greediness): Per default, gli operatori come * sono “avidi”. Se cerchi di estrarre testo tra virgolette in una stringa che ne ha più coppie, potresti ottenere tutto dal primo all’ultimo apice. Usa l’operatore ? per un matching “pigro”.
-
Indici: Le funzioni RegEx nella clausola WHERE, proprio come LIKE ‘%testo%’, possono causare un Index Scan invece di un Index Seek. Usale con saggezza su tabelle da milioni di righe, magari combinandole con un filtro più restrittivo su una colonna indicizzata.
Conclusione
L’introduzione delle RegEx in SQL Server 2025 non è solo una “comodità”; è un salto di qualità nella Data Quality. Ci permette di spostare la logica di validazione vicino ai dati, riducendo la complessità del codice applicativo e migliorando la manutenibilità.
Il mio consiglio? Inizia oggi stesso a mappare tutte quelle procedure salvate piene di REPLACE nidificati e trasformale in espressioni regolari eleganti. Il tuo “io del futuro” ti ringrazierà quando dovrà fare manutenzione a quel codice tra due anni.
