Riesco finalmente a trovare una manciata di minuti, in questi giorni carichi di lavoro, per poter fare alcune considerazioni sull’importante annuncio che, proprio in questi giorni al MIX è stato dato ma che già da tempo era nell’aria: il servizio di Database-On-The-Cloud (SQL Server Data Services) fornito da Microsoft con la sua piattaforma Azure, supporterà nativamente il protocollo TDS, oggi in uso da SQL Server!
Oltre a questo ci sarà il pieno supporto di:
- Tabelle
- Stored Procedures
- Triggers
- Views
- Indexes
Il tutto implmentato assicurando tutte le proprietà ACID, necessarie per avere un sistema realmente transazionale.
Cià significa poter avere un RDBMS disponibile “on the Cloud” veramente. Non un sistema di storage o di persistenza, ma un database relazionale a tutti gli effetti! Per la cronoca il motore è basato sull’engine di SQL Server 2008, il che rende bene l’idea della scalabilità che può raggiungere.
Il fatto che il protocollo di comunicazione sia il TDS è un grande vantanggio in quanto sarà molto facile (banale oserei dire) “switchare” da un database on-the-cloud (SSDS) ad uno locale (SQL Server 2008) e/o viceversa. Sicuramente un’ottima mossa da parte di MS. Ottima insieme alla possibiltà di poter gestire i propri database remoti direttamente dal Management Studio!
Posto che i vantaggi di avere un db on-the-cloud sono da verificare attentamente, credo che sia bene però chiarire sin da subito che una soluzione remota come questa necessiti di una particare attenzione al design del database, cercando di fare in modo che non ci sia mai nessuno spreco in termini di dati scambiati, dato che la latenza del web è assolutamente superiore a quella di una qualisiasi LAN e che la velocità di trasferimento dati è ordini di grandezza inferiore. Chiaro che se si pensa di costrutire un’applicazione completamente web-based questi problemi si possono anche ignorare ma credo che per chiunque arrivi prima o poi la necessità di avere i dati “in casa”. Vuoi per analisi, vuoi per motivi di integrazione con altre applicazioni non on-the-cloud al 100%, penso che nei prossimi anni questa necessità di verificherà di frequente.
E’ quindi importante avere un database ben normalizzato, dato che la normalizzazione assicura la totale assenza di duplicazioni (e quindi spreco di spazio, oltre che possibilità di inconsistenza dei dati), ed uno schema fisico ben disegnato, dato che, come già ripetuto più volte, è fondamentale, scegliere, per le colonne di una tabella, il tipo di dato più corretto (ossia quello che calza a pennello) per i dati che vi devono essere contenuti.
Per chi volesse avere un’idea di tutto quello che SSDS promette, è possibile leggere una bella serie di FAQ direttamente redatta dal team di sviluppo, qui:
http://blogs.msdn.com/ssds/archive/2009/03/12/9471765.aspx
Senza dubbio il futuro che si delinea all’orizzonte assicura che non ci annoieremo :-)