Selena Deckelmann ha pubblicato sul planet un articolo a mio avviso troppo complicato per spiegare un problema piuttosto semplice: la necessita' di specificare sempre in una istruzione INSERT tutte le colonne coinvolte nel comando stesso.
E lo stesso vale per SELECT, aggiungo io.
A mio avviso dovrebbe essere prassi consolidata quella di non usare mai, in produzione, comandi SQL incompleti (INSERT senza colonne e SELECT *), ma qualora non lo fosse e' giusto ricordare le motivazioni.
La prima e' il riordino, aggiunta, eliminazione di una o piu' colonne. In questo caso l'ordine dei valori di una INSERT o l'output di una SELECT * cambia formato, e quindi non e' piu' affidabile.
La seconda motivazione e' il cast: a volte e' necessario informare esplicitamente il database su come usare un tipo di dato in ingresso/uscita, e nel caso di INSERT via SELECT si potrebbero avere anche tipi molto differenti fra loro (es. inserire una data come testo).
La terza riguarda l'accesso ai dati: non indicando esplicitamente quali colonne si vanno a manipolare si rischia di agire su troppi dati, e ad esempio mostrare (o inviare) colonne che non dovrebbero essere effettivamente visibili.
C'e' poi anche una motivazione di manutenzione: nonostante sia forte la tentazione di passare per la scorciatoia di non indicare le colonne, il fatto di elencarle esplicitamente consente di individuare esattamente tutti e soli i punti che agiscono su un determinato attributo, semplificando il mantenimento del codice, la ricerca di bug e il refactoring.
In altre parole, mai usare le "scorciatoie" se non si sta facendo solo una query one-shot su un sistema di test.
E per prassi, nell'era degli editor super-evoluti, non vi e' ragione per usarla nemmeno su quei sistemi.
Nessun commento:
Posta un commento