In questo post annunciavo la disponibilità della versione preliminare del SP2 di SQL Server 2005 che introduceva alcune nuove funzionalità.

Ho già dedicato un post pochi giorni fa ai Logon Trigger e mi ero ripromesso al più presto di approfondire i vardecimal. Come noto i dati di tipo decimal vengono trattati dallo storage engine di SQL Server come dati a lunghezza fissa e le dimensioni richieste per la loro memorizzazione dipendono dalla precisione con cui è stato dichiarato il datatype. Ad esempio se dichiariamo un campo come DECIMAL (12, 2) il Book OnLine di SQL Server ci dice che tale valore occuperà la bellezza di 9 byte a prescindere se il valore memorizzato sia 0,5 oppure se sia 9.000.000.000,00. Con il SP2 sarà possibile risparmiare spazio di memorizzazione utilizzando il datatype vardecimal i cui benefit in termini di spazio sono proporzionali alla differenza tra il valore massimo ammesso (ovvero la precisione del datatype) e la "media" dei valori memorizzati.

Se per un dato campo si è dovuto scegliere un datatype decimal con precisione elevata ma solo pochi valori richiedono tale elevata precisione mentre per la gran parte sarebbe sufficiente un numero molto basso ecco che il vardecimal promette di risparmiare spazio di memorizzazione. In linea teorica tale risparmio dovrebbe anche tradursi in una maggior efficienza (fatto salvo l'overhead per la loro gestione) dal momento che, in linea di principio, un record più compatto consente di stipare in una pagina dati un numero più elevato di informazioni che si traduce in un IO ridotto per accedere alla stessa quantità di record. Analogamente dovrebbero essere più efficienti tali campi se facenti parte della definizione di un indice. Il condizionale è d'obbligo, almeno per ora, in attesa di maggiori informazioni sugli overhead necessari al sistema per la gestione di tali datatype.

Sono benefit, questi, che, se confermati, vanno ben al di la del risparmio di spazio su disco in considerazione dell'abbattimento dei costi di storage. Tuttavia mi sono interrogato da subito sul rovescio della medaglia, ovvero che una innovazione così pesante riguardante lo storage engine non può essere tanto indolore e cosa succederebbe se tento di ripristinare un backup di un database in cui ho implementato tale funzionalità su una istanza in cui non ho installato il SP2?

Beh, ero quasi certo della risposta ed oggi, prima ancora di eseguire delle prove, ne ho avuto la conferma in questo post.

Fortunatamente tale funzionalità sarà implementata solo sulla versione Enterprise (ed ovviamente anche sulla Developer) e non sarà pertanto rivolta a quelle installazioni medio-piccole dove il più delle volte chi gestisce il sistema ed effettua gli aggiornamenti non legge neanche il ReadMe che accompagna il SP.

Personalmente sono contrario all'introduzione di nuove feature nei Service Pack che dovrebbero invece limitarsi a correggere bug, migliorare eventualmente l'interfaccia grafica e i tools di gestione ma non dovrebbero apportare cambiamenti che limitano, come in questo caso, la portabilità di un database da un server ad un'altro.

Buon anno a tutti...