Würden Sie diese einfache SQL zur Nacharbeit senden?

Question

Wir haben eine Webanwendung, in der die Benutzer Ad-hoc-Abfragen basierend auf Parametern ausführen, die eingegeben wurden. Ich könnte auch erwähnen, dass die Antwortzeit für die Benutzer von großer Bedeutung ist.

Die Webseite erstellt dynamisch eine SQL, die basierend auf den eingegebenen Parametern ausgeführt wird. Zum Beispiel, wenn der Benutzer gibt „1“ für „Business Unit“ wir eine SQL wie folgt konstruieren:

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

Ich fand, dass, wenn der Benutzer keine BUSINESS_UNIT die folgende Abfrage erstellt angeben hat sich

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

IMHO, das ist unnötigerweise (wenn nicht grob) ineffizient und garantiert das Senden des Codes schlecht für die Änderung, aber da ich eine viel höhere Rate Code zurück zur Nachbearbeitung als andere habe, glaube ich, dass ich einen Ruf verdienen kann als " zu wählerisch."

Wenn dies eine unpassende Frage ist, weil es keine direkte Codierung Q ist, lassen Sie es mich wissen und ich werde es sofort löschen. Ich bin sehr verwirrt, ob subjektive Fragen wie diese erlaubt sind oder nicht! Ich werde deine Antworten beobachten.

ty

---

Update:

Ich bin mit einer Oracle-Datenbank.

Mein Eindruck ist, dass Oracle "LIKE '%'" nicht optimiert, indem die Bedingung entfernt wird und dass es weniger effizient ist. Könnte jemand bestätigen?

Answer 1

Obwohl das grob ineffizient aussieht, habe ich es gerade in SQL Server getestet, und der Abfrageoptimierer war intelligent genug, um es herauszufiltern.

Mit anderen Worten,

SELECT * FROM FACT WHERE 
BUSINESS_UNIT LIKE '%' 

und

SELECT * FROM FACT 

erzeugen genau die gleichen Abfrage-Plan. Es sollte also keinen Leistungsunterschied geben (abhängig von Ihrer DB-Engine, denke ich), obwohl es irgendwie schlampig aussieht.

Das kann Ihre Entscheidung beeinflussen, es zurück zu senden oder nicht. Persönlich würde ich wahrscheinlich, aber wenn Sie bereits unter einer Wolke sind, dann ist es etwas, auf dem Sie wahrscheinlich entspannen können, zumindest in Bezug auf die Leistung.

Answer 2

Ich würde es zurückschicken und ich mag die Frage.

Alle Code-Review ist in gewissem Maße subjektiv. Die Kriterien sollten auf einer Reihe von Faktoren basieren.

• Funktioniert es.

• Ist es vernünftig Erwartungen an Leistung, Wartbarkeit, Benutzerfreundlichkeit und Skalierbarkeit erfüllt

Während ich dieses besondere Konstrukt nicht getestet haben - ich vermute, (wie Sie) dieser Code schreckliche Dinge tun, um Ihr SQL-Server. Damit werden Leistung und Skalierbarkeit in Frage gestellt.

Answer 3

Diese Abfrage, mit der BUSINESS_UNIT LIKE '%', sieht nicht sehr effizient - ich nehme an, es einen Scan der Tabelle ...

ja, zwingen werde

Also, ich würde versuchen, diese Abfrage überarbeitet haben Um mit dieser Art von Situation richtig umzugehen - oder zumindest würde ich dieses Problem durch unseren Bug-Tracker melden(Nicht sicher von der Priorität, die ich zuweisen würde, aber, noch, das Problem wäre irgendwo geloggt, und jemand wird es irgendwann korrigieren, wenn es kein Problem mit höherer Priorität gibt, mit dem man sich befassen muss..

Answer 4

Der Schreiber wollte eine Dummy-Anweisung, damit er/sie alle nachfolgenden Anweisungen anfügen kann. Ändern Sie es in eine bessere "no-op" -Anweisung wie 1 == 1 würde helfen. Oder sie könnten etwas mehr arbeiten und das "Wo" intelligent einfügen.

Answer 5

SELECT * ist eine rote Flagge. Geben Sie eine Spaltenliste für die Abfrage an.

Answer 6

Die beiden Abfragen sind völlig verschieden (aus der Sicht eines Ergebnismenge)

SELECT * FROM FACT; 

und

SELECT * FROM FACT WHERE 
BUSINESS_UNIT LIKE '%'; 

Die erste wird alle Zeilen zurückgeben, die zweite, wenn es NULL sind Werte diese Zeilen werden nicht zurückgegeben, da alles im Vergleich zu NULLNULL ist und daher das Prädikat nicht erfüllt. So würde es in Oracle funktionieren.

Answer 7

Ich würde fragen, warum Bind-Variablen nicht verwendet werden (es sei denn es einen guten Grund in besonderen Fällen ist):

SELECT * FROM FACT WHERE 
BUSINESS_UNIT = '1' 

Warum ist es nicht:

SELECT * FROM FACT WHERE 
BUSINESS_UNIT = :bu