Topics tagged with sql

Azure Data Studio è in pensione: migra il tuo workflow Azure SQL su VS Code in 10 minuti

blog@spcnet.it — Thu, 30 Apr 2026 08:42:52 GMT

Se stai ancora aprendo Azure Data Studio per lavorare con Azure SQL, è arrivato il momento di fare il passo. Azure Data Studio (ADS) è andato ufficialmente in pensione il 6 febbraio 2025, e il supporto è terminato il 28 febbraio 2026. Microsoft ha indicato Visual Studio Code con l’estensione MSSQL come percorso ufficiale consigliato.Questa guida ti aiuta a ripristinare rapidamente la produttività in VS Code: importare il setup esistente, recuperare le scorciatoie familiari come F5, e far funzionare SQL Database Projects per gestire le modifiche allo schema con sicurezza.Perché questa migrazione conta per gli sviluppatori Azure SQLEseguire query è solo una parte del lavoro. La maggior parte dei team ha bisogno di workflow ripetibili per la revisione delle modifiche allo schema, la validazione in CI, e i deployment più sicuri. SQL Database Projects supporta questo stile di lavoro con “schema as code”, build validation, e un’esperienza di pubblicazione guidata direttamente in VS Code.Rispetto ad Azure Data Studio, VS Code offre:Un ecosistema di estensioni molto più ricco e aggiornatoIntegrazione nativa con GitHub Copilot per l’assistenza SQLSupporto per SQL database in Microsoft FabricUn editor più potente con refactoring, IntelliSense avanzato, e integrazione Git integrataStep 1: Installa gli strumenti SQL essenziali per VS CodeDalla Marketplace di VS Code, installa questi tre componenti:Estensione MSSQLIl tuo principale strumento per query, connessioni e workflow con il database. Cerca “SQL Server (mssql)” nel VS Code Marketplace. Questa estensione gestisce le connessioni ai server SQL Server, Azure SQL Database, Azure SQL Managed Instance e SQL database in Microsoft Fabric.SQL Database ProjectsAggiunge il sistema di progetto e il workflow di build/publish per “schema as code”. Cerca “SQL Database Projects” nel Marketplace. Con questa estensione puoi organizzare oggetti SQL in un progetto versionabile, validare la struttura del database prima del deploy, e pubblicare in modo controllato..NET 8 SDKSQL Database Projects dipende dal .NET SDK per la build. Installalo da dotnet.microsoft.com prima del primo build. L’estensione ti avviserà se manca, ma averlo pronto evita un riavvio aggiuntivo.Step 2: Importa il tuo setup ADS esistenteL’estensione MSSQL include un ADS Migration Toolkit che trasferisce le tue connessioni salvate, i gruppi di connessioni, le impostazioni e i binding dei tasti in un unico flusso guidato. Apri l’estensione e segui il wizard.Ripristinare F5 come abitudine muscolareSe sei abituato a premere F5 per eseguire una query in Azure Data Studio, installa l’estensione MSSQL Database Management Keymap. Aggiunge i binding di tasti in stile ADS, incluso F5 per eseguire una query. Per l’elenco completo, consulta la documentazione “Customize keyboard shortcuts”.Step 3: Configurare SQL Database Projects end-to-endQuesta è la parte che rende il workflow davvero solido. Segui questi passaggi nell’ordine:1. Crea o apri un progetto SQLApri una cartella di progetto SQL esistente in VS Code, oppure creane uno nuovo tramite i comandi SQL Database Projects nell’editor. I file .sqlproj sono compatibili con SSDT, quindi puoi aprire progetti esistenti direttamente.2. Esegui prima la buildIl primo traguardo deve essere una build pulita. Confermare che la toolchain è configurata correttamente prima di tentare un deploy è fondamentale. Eventuali errori di sintassi o riferimenti mancanti emergono qui, non in produzione.3. Pubblica tramite il Publish DialogFai clic destro sul progetto nel pannello Database Projects, seleziona Publish, configura il target, controlla il deployment script generato, e seleziona Publish per deployare.La preview dello script è il punto che rende questo workflow affidabile per uso serio: vedi esattamente quale T-SQL verrà eseguito sul database prima che accada. Niente sorprese.Problemi comuni e soluzioni.NET SDK non trovato: Se la prima build non completa, verifica che il .NET SDK sia installato e che VS Code riesca a trovarlo. Questo è il problema più comune al primo avvio.Target platform mismatch: Se il comportamento di publish è diverso da quello atteso, controlla il target platform del progetto nelle impostazioni .sqlproj. Molti problemi di publish dipendono dalla configurazione del progetto, non dal database in sé.Lavorare con SQL database in Microsoft FabricLa stessa configurazione VS Code si applica a SQL database in Microsoft Fabric, con un’aggiunta: inizia dal portale Fabric per collegare il database a Git prima di aprire il progetto localmente in VS Code. Questo garantisce che il file di progetto sia configurato correttamente per Fabric.Item templates: per chi arriva da SSDTSe vieni da SSDT, i template di elementi in SQL Database Projects generano stub consistenti per tabelle, stored procedure, view e altri oggetti comuni. Fai clic destro sul progetto nel pannello Database Projects e seleziona Add Item per iniziare.Primi passi consigliatiProva questo ciclo completo con qualsiasi schema di database piccolo:Crea o apri un SQL projectEsegui la buildPubblica con script preview abilitatoApporta una modifica allo schema, ricompila, e pubblica di nuovoDopo questo ciclo, il workflow ti sembrerà naturale come quello di Azure Data Studio — con in più la potenza dell’ecosistema VS Code.ConclusioneAzure Data Studio ha avuto la sua era, ma VS Code con l’estensione MSSQL è oggi il tool ufficiale e più potente per lavorare con Azure SQL. L’importazione del setup esistente richiede pochi minuti grazie all’ADS Migration Toolkit, e SQL Database Projects porta il workflow di schema management a un livello superiore rispetto a quanto era possibile in ADS.Chi lavora con Azure SQL, SQL Server, o SQL database in Microsoft Fabric troverà in VS Code un ambiente più ricco e costantemente aggiornato. La transizione vale lo sforzo.Fonte originale: Azure Data Studio is retired: Move your Azure SQL workflow to VS Code in 10 minutes — Iqra Shaikh, Microsoft Azure SQL Dev Corner (27 aprile 2026)

12 tecniche per ottimizzare le query PostgreSQL su dataset di grandi dimensioni

blog@spcnet.it — Wed, 22 Apr 2026 15:21:43 GMT

Quando una tabella PostgreSQL cresce oltre il milione di righe, query che prima restituivano risultati in millisecondi iniziano ad impiegare secondi — o peggio. La buona notizia è che PostgreSQL offre strumenti potenti per affrontare questo problema. La cattiva notizia è che molti sviluppatori conoscono solo una parte di questi strumenti.In questo articolo passiamo in rassegna le 12 tecniche più efficaci per ottimizzare le query su grandi dataset, con esempi SQL concreti per ciascuna.1. Creare indici sulle colonne frequentemente filtrateIl consiglio più noto, ma non per questo meno importante. Un indice trasforma una scansione sequenziale (O(n)) in una ricerca B-tree (O(log n)). La differenza su una tabella da un milione di righe può essere di due ordini di grandezza.-- Prima: full sequential scan su ordini SELECT * FROM orders WHERE customer_id = 42;  -- Creazione dell'indice CREATE INDEX idx_orders_customer_id ON orders(customer_id);  -- Dopo: index scan, da 240ms a pochi msUsate EXPLAIN ANALYZE per verificare che l’indice venga effettivamente utilizzato.2. Normalizzare il database in modo strategicoLa normalizzazione riduce la ridondanza e migliora la coerenza dei dati, ma va applicata con giudizio. Una normalizzazione eccessiva crea decine di JOIN che possono diventare colli di bottiglia. La regola pratica: normalizzate i dati che cambiano spesso o che hanno alta cardinalità (liste di prodotti, clienti, categorie), denormalizzate i dati storici o di report dove la velocità di lettura è critica.3. Evitare SELECT *Selezionare tutte le colonne ha due costi nascosti: aumenta il volume di I/O e impedisce a PostgreSQL di soddisfare la query direttamente dall’indice (index-only scan). Specificate sempre le colonne necessarie:-- Evitare SELECT * FROM orders WHERE customer_id = 42;  -- Preferire SELECT id, created_at, total_amount FROM orders WHERE customer_id = 42;Quando le colonne selezionate fanno parte di un indice composito, PostgreSQL può restituire i dati senza accedere all’heap, eliminando un intero livello di I/O.4. Ordinare i JOIN in modo efficienteIl query planner moderno di PostgreSQL determina autonomamente l’ordine ottimale dei JOIN grazie al cost-based optimizer. Tuttavia, in scenari con molte tabelle o con join_collapse_limit ridotto, conviene strutturare i JOIN in modo che le tabelle più piccole (o più filtrate) vengano processate per prime, riducendo la cardinalità delle operazioni successive.5. Usare LIMIT durante l’esplorazione dei datiApparentemente ovvio, ma spesso trascurato: se l’interfaccia utente mostra al massimo 50 risultati, non ha senso recuperarne un milione dal database.SELECT id, name, email  FROM customers  ORDER BY created_at DESC  LIMIT 50 OFFSET 0;Attenzione al pagination problem: con OFFSET elevati, PostgreSQL scansiona comunque tutte le righe precedenti. Per paginazione su grandi dataset, preferite il keyset pagination (cursor-based).6. Indici parziali per subset frequentiUn indice parziale indicizza solo le righe che soddisfano una condizione, riducendo dimensioni e costo di manutenzione:-- Indice solo sugli ordini completati (subset più frequentemente interrogato) CREATE INDEX idx_completed_orders ON orders(customer_id) WHERE status = 'Completed';  -- La query deve includere la stessa condizione per usare l'indice SELECT id, total_amount  FROM orders  WHERE customer_id = 42 AND status = 'Completed';In un test pratico, questo indice ha dimezzato i tempi rispetto a un indice standard su tutte le righe.7. Usare i tipi di dato più piccoli necessariOgni byte conta quando moltiplicato per milioni di righe. Preferite sempre il tipo più compatto che soddisfa il requisito:integer (4 byte) invece di bigint (8 byte) per chiavi primarie < 2 miliardismallint (2 byte) per enumerazioni con pochi valoritimestamp invece di timestamptz se il fuso orario è fissovarchar(n) con limite appropriato invece di text illimitato dove possibileTipi più piccoli significano pagine di dati più dense, quindi meno I/O per ogni query.8. Non applicare funzioni sulle colonne indicizzateApplicare una funzione a una colonna indicizzata invalida l’utilizzo dell’indice:-- L'indice su name NON viene usato SELECT * FROM customers WHERE LOWER(name) = 'mario rossi';  -- Soluzione: creare un indice funzionale CREATE INDEX idx_customers_lower_name ON customers(LOWER(name));  -- Ora l'indice viene usato SELECT * FROM customers WHERE LOWER(name) = 'mario rossi';Lo stesso vale per funzioni su date come DATE(created_at): usate range di timestamp o create l’indice sulla funzione.9. Partizionare le tabelle molto grandiIl partizionamento divide una tabella logica in sotto-tabelle fisiche, permettendo a PostgreSQL di escludere partizioni irrilevanti (partition pruning) durante le query:-- Tabella partizionata per anno CREATE TABLE orders_partitioned (  id serial NOT NULL,  customer_id integer,  created_at timestamp NOT NULL,  CONSTRAINT pk_orders PRIMARY KEY (id, created_at) ) PARTITION BY RANGE (created_at);  -- Creazione delle partizioni annuali CREATE TABLE orders_2024 PARTITION OF orders_partitioned  FOR VALUES FROM ('2024-01-01') TO ('2025-01-01');  CREATE TABLE orders_2025 PARTITION OF orders_partitioned  FOR VALUES FROM ('2025-01-01') TO ('2026-01-01');Una query che filtra per anno legge solo la partizione corrispondente, ignorando completamente le altre.10. Usare le transazioni per operazioni bulkPostgreSQL esegue un commit (e quindi una scrittura sincrona su WAL) dopo ogni statement. Raggruppare più operazioni in un’unica transazione riduce drasticamente i costi di I/O:-- Lento: un commit per ogni INSERT INSERT INTO log_events VALUES (...); INSERT INTO log_events VALUES (...); -- ... x 10.000  -- Veloce: un solo commit per tutto il batch BEGIN; INSERT INTO log_events VALUES (...); INSERT INTO log_events VALUES (...); -- ... x 10.000 COMMIT;In test pratici, l’approccio con transazione singola completa lo stesso lavoro in meno della metà del tempo rispetto agli inserimenti individuali.11. Evitare transazioni long-runningIl modello MVCC (Multi-Version Concurrency Control) di PostgreSQL mantiene versioni multiple delle righe per garantire la consistenza delle letture. Le transazioni long-running bloccano il processo di VACUUM dal rimuovere le versioni obsolete, causando table bloat: tabelle che crescono fisicamente anche quando i dati logici non aumentano.Spezzettate le operazioni pesanti in batch più piccoli e monitorate le transazioni attive con:SELECT pid, now() - pg_stat_activity.query_start AS duration, query, state FROM pg_stat_activity WHERE state != 'idle' AND query_start IS NOT NULL ORDER BY duration DESC;12. Gestire il bloat con VACUUMOgni UPDATE e DELETE lascia righe “morte” sul disco. VACUUM le recupera:-- VACUUM standard: recupera spazio senza bloccare le letture VACUUM orders;  -- VACUUM FULL: recupera tutto lo spazio ma blocca l'accesso alla tabella -- Usare solo in finestre di manutenzione programmate VACUUM FULL orders;  -- Verificare lo stato del bloat SELECT relname, n_dead_tup, n_live_tup,  round(n_dead_tup::numeric / NULLIF(n_live_tup + n_dead_tup, 0) * 100, 2) AS dead_pct FROM pg_stat_user_tables ORDER BY n_dead_tup DESC LIMIT 20;Per la maggior parte dei workload, autovacuum è sufficiente. Assicuratevi che sia abilitato e calibrate i threshold in base al volume di modifiche della vostra applicazione:-- Verificare la configurazione autovacuum per una tabella specifica SELECT reloptions FROM pg_class WHERE relname = 'orders';Riepilogo operativoNon tutte le tecniche si applicano a ogni scenario. Un approccio efficace inizia sempre dall’analisi con EXPLAIN (ANALYZE, BUFFERS) per identificare i reali colli di bottiglia, poi applica le ottimizzazioni in modo mirato. L’indice sbagliato o il partizionamento mal configurato possono peggiorare le prestazioni invece di migliorarle.Il punto di partenza universale resta lo stesso: misurare prima, ottimizzare dopo.Fonte: 12 practices for optimizing PostgreSQL queries for large datasets — elmah.io Blog