Risorse

Mi è capitato spesso di confrontarmi con colleghi a proposito della scelta più adatta tra le versioni di SQL Server.

La prima scelta riguarda quella tra PaaS (Platform as a Service) e IaaS (Infrastructure as a Service).

Nel caso si scelga IaaS si procederà alla creazione di una VM Azure oppure alla scelta tra quelle offerte nella gallery da Microsoft facendosi carico dell’amministrazione della VM stessa (aggiornamenti, applicazione di patch, ecc.). In questo link trovate le informazioni sul licensing delle VM.

Immaginate di dover ripristinare un database dall’ambienti di produzione a quello di sviluppo per permettere agli sviluppatori di effettuare dei test su dati reali. Si pone il problema di offuscare informazioni riservate che possono essere il nome utente, il numero di carta di credito, ecc. ecc.

Il metodo tradizionale impone al dba di lanciare immediatamente una query sulle tabelle interessate per offuscare le informazioni riservate. Pur avendo tutti gli script a disposizione occorrerebbe eseguirli sul database e attendere il termine dell’esecuzione generando traffico “inutile” (specie su database molto grandi).

’Strech DB’ é la nuova feature di SQL Server 2016 che promette di risolvere l’annoso problema dell’archiviazione dei Cold Data: i dati che col tempo perdono di interesse (vi si accede sempre meno spesso) ma non di valore, per cui non ce ne si puó disfare e si tende, invece, ad archiavarli in qualche modo.

‘Strech DB’ permette di spostare nel cloud (SQL Azure) le righe di tabella in modo del tutto trasparente all’utente, il quale continua ad avere accesso all’intero set di righe della tabella la cui parte Cold esiste di fatto nel cloud mentre quella Hot resta on-premis.

Una delle richieste tipiche di un utente è quella di poter user Excel non solo per consultare i dati che stanno dentro un database (relazionale o meno) ma anche di poterli modificare. Sarebbe in effetti estremamente comodo, magari anche solo per i casi più semplici di piccole tabelle di configurazione, poter evitare di dover sviluppare una GUI ad-hoc tutte le volte, oppure di trovare workaround più o meno efficaci per fare in modo che l’utente possa evitare di dover dialogare con il database a colpi di SQL (o, peggio, di altri linguaggi non standard)

Uno dei problemi storici nello sviluppo dei database è quello di tenere lo schema del database sotto controllo, ed evitare pericolosi ed inaspettati drift, ossia scostamenti dallo schema che ci si aspetta di avere.

I motivi per cui questi drift succedono sono innumerevoli, e sono chiaramente legati al fatto che il database è un oggetto condiviso che non è per nulla semplice da mettere sotto controllo. Inutile far finta di nulla, penso che ognuno di noi abbia assistito ad una qualche modifica fatta direttamente in produzione. La cosa dovrebbe farvi inorridire….ma sappiamo com’è la realtà, quindi inutile ignorarla.