Nel
post precedente, ho parlato di come il motore interpreta le variabili locali, con la possibilità che questo possa anche degradare le performance delle nostre query.
In effetti, lavorando anche lato dev, mi rendo conto di come la mancanza di vere e proprie COSTANTI in programmabilità T-SQL si faccia sentire.
Ragion per cui mi sono posto un (credo) annoso problema, ovvero: "Come gestire le nostre CONST?".
Come dicevamo
qui, non è per nulla indicato usare variabili locali, nemmeno all'interno di stored procedure. E' vero, la documentazione ci invita a seguire altre strade, come:
- utilizzare la sp_executeSQL
Sinceramente non vorrei andare a creare per ogni variabile locale che vorrei usare come costante, una stringa dinamica, il rovescio della medaglia è immediato,
non so cosa vado a scrivere nel mio sql dinamico, perdo tutto quanto posso catturare in compilazione delle stored procedure e le eventuali dipendenze..
Insomma non la trovo la via migliore se non nel particolare.
- non utilizzare variabili locali bensì literal diretti
Se nelle stored procedure volessi includere un pochino di logica per cui già una literal va ripetuto un paio di volte, ci perdo in manutenibilità e aumento la possibilità di errore.
Pensate ad una costante usata in 5 posti, è comodo dichiararla in testa, ma è anche più affidabile e sicuro, perchè mai dovrei scrivere 5 volte lo stesso valore? E poi, quando lo devo cambiare?
Se chi modifica non sa che sono 5 e me ne cambia 3? Potenzialmente distruggo anche una parte di consistenza applicativa.
Per ora, qualora mi servano costanti, utilizzo una variabile locale, i piani direi che reggono benone e le macchine mi danno risultati eccellenti. Sicuramente potrei migliorare di un po' le performance, ma, seguendo o il primo o il secondo metodo, perderei troppe altre cose a mio modo di vedere. Ho trovato però questo
link interessante, su cui varrebbe la pena di fare un pensierino. Il CLR potrebbe essere una buona soluzione.
Stay Tuned!
