Vuoi inviare questo semplice SQL indietro per la rilavorazione?

Question

Abbiamo un'applicazione Web in cui gli utenti eseguono query ad-hoc in base ai parametri immessi. Potrei anche menzionare che il tempo di risposta è di grande importanza per gli utenti.

La pagina Web crea dinamicamente un SQL da eseguire in base ai parametri immessi. Ad esempio, se l'utente immette "1" per "Business Unit" costruiamo uno SQL come questo:

SELECT * FROM FACT WHERE 
BUSINESS_UNIT = '1' 
--AND other criteria based on the input params 

ho scoperto che in cui l'utente non specifica un BUSINESS_UNIT la seguente query è costruito

SELECT * FROM FACT WHERE 
BUSINESS_UNIT LIKE '%' 
--AND other criteria based on the input params 

IMHO, questo è inutilmente (se non grossolanamente) inefficiente e garantisce l'invio del codice errato per la modifica ma dal momento che ho una velocità molto più alta di invio del codice per la rilavorazione rispetto ad altri, credo che potrei guadagnarmi una reputazione come " troppo schizzinoso. "

Se questa è una domanda inappropriata perché non è una codifica diretta Q, fammelo sapere e la eliminerò immediatamente. Sono molto confuso se le domande soggettive come questa siano permesse o no! Guarderò le tue risposte.

ty

---

Aggiornamento:

Sto usando un database Oracle.

La mia impressione è che Oracle non ottimizzi "LIKE '%'" rimuovendo la condizione e che lasciarla sia meno efficiente. Qualcuno potrebbe confermare?

Answer 1

Anche se questo sembra gravemente inefficiente, l'ho appena testato su SQL Server, e Query Optimizer era abbastanza intelligente da filtrarlo.

In altre parole,

SELECT * FROM FACT WHERE 
BUSINESS_UNIT LIKE '%' 

e

SELECT * FROM FACT 

generati stesso piano esatto di query. Quindi non ci dovrebbe essere una differenza di prestazioni (a seconda del tuo motore DB credo), anche se sembra piuttosto sciatta.

Ciò potrebbe influire sulla decisione di reinvio o meno. Personalmente probabilmente lo farei, ma se sei già sotto una nuvola allora è qualcosa su cui probabilmente ti puoi rilassare, almeno in termini di prestazioni.

Answer 2

Vorrei rispedirlo e mi piace la domanda.

Tutta la revisione del codice è in qualche misura soggettiva. I criteri dovrebbero essere basati su una serie di fattori.

• Funziona.

• vuol soddisfare ragionevoli aspettative di prestazioni, manutenibilità, usabilità e scalabilità

Anche se non ho ancora testato questo particolare costrutto - Ho il sospetto (come si fa) questo codice farà cose orribili a il tuo server SQL. Quindi le prestazioni e la scalabilità sono chiamate in causa.

Answer 3

Quella domanda, con il BUSINESS_UNIT LIKE '%', non sembra abbastanza efficiente - suppongo che sarà forzare una scansione completa della tabella ...

Quindi, sì, cercherei di avere quella query rielaborato , per affrontare quel tipo di situazione in modo corretto - o, almeno, segnalerei questo problema tramite il nostro bug-tracker(Non sono sicuro della priorità che assegnerei, ma, comunque, il problema sarebbe registrato da qualche parte e qualcuno lo correggerà un giorno, quando non ci sono problemi con priorità più alta da trattare).

Answer 4

Lo scrittore voleva una dichiarazione fittizia in modo che lui/lei potesse aggiungere "e" a tutte le dichiarazioni successive. cambiarlo in una migliore "no-op" come 1 == 1 sarebbe d'aiuto. Oppure potrebbero fare un po 'più di lavoro e inserire il "dove" in modo intelligente.

Answer 5

SELECT * è una bandiera rossa. Specificare un elenco di colonne per la query.

Answer 6

Le due query sono completamente diversi (dal punto di vista di un set di risultati)

SELECT * FROM FACT; 

e

SELECT * FROM FACT WHERE 
BUSINESS_UNIT LIKE '%'; 

Il primo restituirà tutte le righe, la seconda, se ci sono NULL i valori di tali righe non verranno restituiti perché nulla rispetto a NULL è NULL e pertanto non soddisfa il predicato. Questo è come avrebbe funzionato in Oracle.

Answer 7

vorrei chiedere perché variabili di bind non vengono utilizzati (a meno che non ci sia una buona ragione in casi particolari):

SELECT * FROM FACT WHERE 
BUSINESS_UNIT = '1' 

Perché non è vero:

SELECT * FROM FACT WHERE 
BUSINESS_UNIT = :bu