Un post di oggi di Igor mi ha stimolato a scrivere un articolo che da qualche giorno ho nel cassetto. L'idea mi è venuta da quando ho assistito alla presetazioni di Paul Nielsen riguardo alla modellazione dei dati, dove, in una slide iniziale, mostrava in modo estramamente chiaro e semplice che impatto hanno sulle performance le ottimizzazioni che possiamo fare su un qualsiasi database (SQL Server 2000 e 2005 in particolare). Il concetto è riassunto da questa piramide:
Che in modo incofutabile comunica che l'impatto maggiore sulle prestazioni è dato da questa sequenza:
1 - Modello del database
Se il database è disegnato male (troppo o troppo poco normalizzato, tabelle con tipi di dati non corretti, e via dicendo) abbiamo un grosso problema. Questo livello è messo alla base di tutti gli altri non a caso; l'efficacia di ogni altra ottimizzazione, infatti, dipende da questo e quindi se il database è disegnato male non ci sarà nessun modo di ottere delle prestazioni davvero ottimali! (A questo si può cercare di porre rimendio tramite del refactoring sul database)
2 - Query
Le query devono essere scritte bene, in particolare per sfruttare al 100% le capacità di elaborazione di set di dati fornite dai database (Quindi niente cursori ed attenzione alle soluzioni row-by-row!). Oltre a questo bisogna prestare attenzione a richiedere solo i dati che ci servono (quindi niente "select *" !) ed a limitare il campo di azione della query (quindi occhio alle clausole where).
3 - Indici
Se il database è fatto bene e le query anche, gli indici fanno la differenza. A titolo informativo (esperienza di vita vissuta) possono migliorare le prestazioni del 1000% (si ho scritto proprio mille!). Gli indici hanno però la "penalità" di occupare spazio (su disco, in memoria, nei backup) e di dover essere mantenuti aggiornati (statistiche comprese).
4 - Concorrenza
Alcune volte le query sono lente perchè ci sono problemi di alta concorrenza sui dati e questo causa colli di bottiglia. Se le query sono fatte bene ed gli indici pure i colli di bottiglia non sono a carico di questi ultimi e sono probabilmente dovuti ad un "semplice" ingolfamento delle risorse. Normalmente ottimizzazioni in questo campo migliorano le prestazioni della singola query e non dell'intero sistema
5 - Server Tuning
Ok, dopo che siete sicuri che tutti gli altri punti sono già perfettamente controllati, è possibile fare del tuning al server in modo da verificare che i colli di bottiglia che creano eventuali attese troppo lunghe non siano da ricondursi ad una macchina sottodimensionata o mal configurata.
Prima che i DBA mi prendano a sassate 
sottolineo che questa piramide è costruita dal punto di vista dello sviluppatore, e quindi si dà per scontato che la macchina sulla quale gira SQL Server sia configurata in modo almeno sufficiente. E' altrettanto vero, infatti, che se la macchina è _davvero_ mal configurata (quindi senza neanche seguire le best practices di base) il punto 5 può diventare uno dei primi da controllare. Il problema verò, però, è che tutti punti sono dipendendenti l'uno dall'altro (anche se l'importanza assegnata dalla piramide a ciascun punto rimane vera) e quindi un database per essere davvero ottimizzato deve essere programmato e amministrato molto ma molto bene.
Dal grafico a piramide, in conclusione, si può dedurre che è bene prendere tutto il tempo che serve (ovviamente senza esagerare) per disegnare il miglor modello dati che possiamo fare, in quanto, essendo posto come fondamenta della nostra struttura, è quello che più ha voce in capitolo in termini di prestazioni ed ottimizzazione ed è anche quello dalla quale tutto il resto dipende....inoltre, il problema dei database, è che una volta che sono messi in produzione hanno una vita media che è il triplo di quella di un'applicazione (quante volte viene rifatta da zero un'applicazione ma il database viene solamente ritoccato?). E' facile immaginare il perchè: una volta che i dati solo dentro nel database, estrarli tutti per importarli in un altro database disegnato meglio è un'operazione tutt'altro che agevole, dispendiosa e facilmente soggetta ad errori....il che si traduce in un database che diventa monolitico ed intoccabile
Spero che questo post aiuti a far chiarezza su questo concetto, putroppo gran parte dei database che ho visto in giro (escudendo io miei, of course ) sono disegnati _davvero_ male, fatti velocemente e da persone senza esperienza in materia. Se non sapete da che parte inziare ho segnalato alcuni libri sul wiki e spero, in futuro, di aver tempo di scrivere un pò di articoli in proposito.