Regola
Da evitare SELECT * in SQL .
SELECT * nelle produzione codice rende le applicazioni
fragili rispetto schema modifiche e nasconde dipendenza dipendenze.
Linguaggi supportati: 45+Introduzione
Utilizzo di SELECT * nelle query di produzione recupera tutte le colonne di una tabella, comprese quelle che la tua applicazione non utilizza. Quando gli schemi dei database si evolvono e vengono aggiunte nuove colonne (compresi dati sensibili come password o informazioni personali identificative), le query che utilizzano SELECT * iniziare automaticamente a recuperarli senza modifiche al codice. Ciò crea vulnerabilità di sicurezza e compromette i presupposti alla base della logica dell'applicazione.
Perché è importante
Impatto sulle prestazioni: il recupero di colonne non necessarie aumenta il tempo di esecuzione delle query, la quantità di dati trasferiti in rete e il consumo di memoria. Una tabella con 50 colonne, quando ne servono solo 5, comporta il trasferimento di una quantità di dati 10 volte superiore al necessario, con conseguente peggioramento dei tempi di risposta e aumento dei costi dell'infrastruttura.
Implicazioni in materia di sicurezza: Le nuove colonne aggiunte alle tabelle (campi di audit, flag interni, dati sensibili degli utenti) vengono automaticamente rese visibili tramite SELECT * richieste. La tua API potrebbe iniziare a divulgare hash delle password, numeri di previdenza sociale o dati aziendali interni che non erano mai stati destinati a quell’endpoint.
Manutenibilità del codice: Quando SELECT * Le query smettono di funzionare dopo le modifiche allo schema; l'errore si verifica in fase di esecuzione, non in fase di compilazione. Una nuova colonna non nullabile o un campo rinominato causano errori in produzione. Gli elenchi espliciti delle colonne rendono chiare le dipendenze e interrompono le build quando gli schemi subiscono modifiche incompatibili.
Esempi di codice
❌ Non conforme:
async function getUserProfile(userId) {
const query = 'SELECT * FROM users WHERE id = ?';
const [user] = await db.execute(query, [userId]);
return {
name: user.name,
email: user.email,
createdAt: user.created_at
};
}
Perché è sbagliato: questa query recupera tutte le colonne, compresi campi potenzialmente sensibili come password_hash, ssn, internal_notes o deleted_at. Man mano che lo schema cresce, questa query diventa più lenta ed espone una quantità maggiore di dati, nonostante l'applicazione ne utilizzi solo tre.
✅ Conforme:
async function getUserProfile(userId) {
const query = `
SELECT name, email, created_at
FROM users
WHERE id = ?
`;
const [user] = await db.execute(query, [userId]);
return {
name: user.name,
email: user.email,
createdAt: user.created_at
};
}
Conclusione
Nelle query SQL specificare sempre elenchi espliciti di colonne. Ciò previene la fuga di dati, migliora le prestazioni e rende chiare le dipendenze tra codice e schema. Il modesto sforzo iniziale richiesto dalla digitazione dei nomi delle colonne consente di evitare intere categorie di problemi relativi alla sicurezza e alle prestazioni.
