Quiz sui dati temporali - la soluzione su SQL Magazine

Tempo fa, prima di partire per l'MVP Summit 2008, proposi un quiz sulla risoluzione delle problematiche temporali:

http://community.ugiss.org/blogs/dmauri/archive/2008/04/09/un-quiz-prima-di-partire-think-set-oriented.aspx

La soluzione non è poi stata più postata...non certo perchè ne me sono dimenticato Smile

Dopo il summit ho avuto modo di passare una settimana con l'amico Itzik, all'evento che abbiamo tenuto a Vienna, e ovviamente ho proposto anche a lui il quiz. Gli è piaciuto molto e mi ha quindi chiesto l'autorizzazione per utilizzarlo per la sua rubrica su SQL Magazine. Detto: fatto! (anche se con i tempi tipici dell'editoria), ed ecco che su questo numero (Ottobre 2008) della rivista potete trovare quiz e soluzione:

http://www.sqlmag.com/Article/ArticleID/99874/sql_server_99874.html

Questo quiz su dati temporali è una evoluzione della situazione già vista e rappresenta una sfida non da poco. Vi invito in primis a risolve il problema da soli, e solo successivamente verificare la soluzione proposta da me e da Itzik: questo genere di quiz ci aiuta ad "aprire la mente" alle soluzioni set-based grazie alle quali possiamo raggiungere risultati altrimenti impossibili, il tutto applicando semplicemente la logica :-).

Sottolineo per l'ennesiva volta che questo è quello che mi piace del modello relazionale. Una volta trovato l'algortimo logico-matematico che funziona sulla carta, è sufficiente riproporlo in linguaggio SQL et voilà, problema risolto! Chissa che LINQ apra la strada a questo genere di approcio anche alla programmazione ad oggetti. Io lo spero proprio, sarebbe un importantissimo passo avanti.

L'articolo è consultabile solo dagli abbonati, per tutti coloro che non sono abbonati a SQL Magazine, il mese prossimo pubblichero un articolo sul sito di UGISS in merito alla cosa, in modo da rendere la soluzione di pubblico dominio.

Published mercoledì 1 ottobre 2008 13.01 by dmauri

Comments

# re: Quiz sui dati temporali - la soluzione su SQL Magazine

giovedì 2 ottobre 2008 10.10 by AlessandroD

Cavolo, per non copiare al 100% la soluzione che avevo postato io, Itzik se ne è uscito nella prima CTE con i 2 union all seguiti da 1 union finale :-)

Arguta idea visto che è sufficiente l'ultimo per eliminare eventuali duplicati generati nelle union all precedenti, che mito quell'uomo!

Vorrei dire la mia anche sulle soluzioni set based pure, sono sicuramente eleganti e pulite, ma come già detto in passato è una tragedia farne il debug, a meno di non avere un accesso più intimo ai singoli passi del piano di esecuzione in modo da sbirciare i resulset intermedi per capire dove sta l'inghippo nel caso in cui i dati finali non corrispondano a quanto voluto.

Un po' di gente ha chiesto la possibilità di avere questa feature attivabile su richiesta in quanto visualizzato dal piano di esecuzione, speriamo bene nelle prossime versione di SQL Server...

Lo stesso dovrebbe essere vero per quanto riguarda LINQ, scrivere in modo dichiarativo delle query per interrogare per esempio un nostro object model è sicuramente elegante e fa risparmiare un bel po' di codice classico, però se la query è un attimo complessa, pure li, fare il debug di perché il risultato finale non è quello che noi vorremmo è veramente difficile.

Tutto IMHO.