Articoli

Punto di partenza

Nel secondo articolo di questa serie abbiamo creato un external model verso Azure OpenAI e abbiamo usato la funzione AI_GENERATE_EMBEDDINGS per generare gli embeddings dei testi presenti nella tabella ai_demo.PostSearchDocuments.

La tabella ai_demo.PostSearchDocuments nel database StackOverflowMini contiene ora due elementi essenziali:

1. I dati grezzi, come titolo, tag, testi delle domande e delle risposte
2. La colonna Embedding, che contiene la rappresentazione vettoriale del testo costruito nella colonna DocumentText

In questo terzo articolo useremo finalmente gli embeddings per eseguire ricerche semantiche direttamente da T-SQL. L’obiettivo è trovare testi simili per significato rispetto a una richiesta espressa in linguaggio naturale, anche quando il testo cercato non coincide esattamente con le parole presenti nei documenti.

Punto di partenza

Nel primo articolo di questa serie dedicata all’applicazione dell’AI sui dati aziendali, abbiamo preparato il terreno per uno scenario di ricerca semantica con SQL Server 2025 o Azure SQL. Usando il database StackOverflowMini, abbiamo creato lo schema ai_demo e la tabella ai_demo.PostSearchDocuments, pensata per contenere documenti testuali costruiti a partire da domande, risposte, tag e metadati della tabella dbo.Posts.

Introduzione

Molto del valore informativo di un’azienda è già nei suoi database: dati relazionali, contenuti testuali, documentazione, ticket e knowledge base. Non sempre, però, filtri, relazioni e ricerche testuali sono sufficienti per trovare informazioni simili per significato.

Con SQL Server 2025, Microsoft porta funzionalità di intelligenza artificiale direttamente nel motore database: nuovo tipo di dato VECTOR, funzioni per lavorare con embeddings, vector search, external model e integrazione con servizi come Azure OpenAI. Queste funzionalità permettono di costruire scenari di ricerca semantica usando T-SQL, accanto al dato relazionale e senza dover ripensare completamente l’architettura dati.

Recentemente ho avuto l’occasione di configurare le impostazioni di networking per un database Azure SQL e desidero condividere un aspetto che non avevo considerato durante le scelte iniziali di deployment della soluzione.

La soluzione comprende un database Azure SQL, un’applicazione e una macchina virtuale Azure che ospita l’applicazione la quale necessita della connessione al database.

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.

Optimized Locking è una funzionalità dell’Engine di SQL Server 2025, è stata implementata per ridurre l’utilizzo della memoria impiegata per la gestione dei lock, ridurre il fenomeno noto con il nome di lock escalation e aumentare la concorrenza dei carichi di lavoro. Nei precedenti articoli di questa serie: SQL Server 2025 Optimized Locking e Optimized Locking Internals: Gestione dei lock in aggiornamenti concorrenti abbiamo descritto rispettivamente il funzionamento generale di Optimized Locking e come avviene la gestione dei lock negli aggiornamenti concorrenti.

Optimized Locking è una funzionalità dell’Engine di SQL Server 2025, è stata implementata per ridurre l’utilizzo della memoria impiegata per la gestione dei lock, ridurre il fenomeno noto con il nome di lock escalation e aumentare la concorrenza dei carichi di lavoro.

In questo articolo abbiamo descritto il funzionamento generale di Optimized Locking, ora passiamo alla pratica, osservando come l’Engine gestisce aggiornamenti concorrenti con Lock After Qualification. Consideriamo la tabella dbo.SalesOrder in un database SQL Server 2025 con Optimized Locking completamente abilitato. La tabella contiene i seguenti dati di prova.