Wir haben eine Web-Anwendung, in der die Benutzer Ad-hoc-Abfragen basierend auf Parametern ausführen, die eingegeben wurden. Ich könnte auch erwähnen, dass die Reaktionszeit für die Benutzer von großer Bedeutung ist.
Die Webseite erstellt dynamisch eine SQL, die basierend auf den eingegebenen Parametern ausgeführt wird. Wenn der Benutzer beispielsweise "1" für "Business Unit" eingibt, erstellen wir eine SQL wie folgt:
%Vor%Ich habe festgestellt, dass, wenn der Benutzer keine BUSINESS_UNIT angibt, die folgende Abfrage erstellt wird
%Vor%IMHO, das ist unnötigerweise (wenn nicht grob) ineffizient und rechtfertigt 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 als verdienen kann "Zu wählerisch."
Wenn das eine unpassende Frage ist, weil es keine direkte Kodierung Q ist, lass 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
Aktualisierung:
Ich verwende eine 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?
Obwohl das grob ineffizient aussieht, habe ich es gerade in SQL Server getestet, und der Abfrageoptimierer war schlau genug, um ihn herauszufiltern.
Mit anderen Worten
%Vor%und
%Vor%hat genau den gleichen Abfrageplan erstellt. 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ückzusenden 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.
Die beiden Abfragen sind völlig verschieden (aus der Sicht einer Ergebnismenge)
%Vor%und
%Vor% Der erste gibt alle Zeilen zurück, der zweite, wenn es NULL -Werte gibt, werden diese Zeilen nicht zurückgegeben, da irgendetwas im Vergleich zu NULL NULL ist und daher das Prädikat nicht erfüllt. So würde es in Oracle funktionieren.
Diese Abfrage mit dem BUSINESS_UNIT LIKE '%' sieht nicht ganz effizient aus - ich denke, es wird einen vollständigen Scan der Tabelle erzwingen ...
Also, ja, ich würde versuchen, diese Frage zu überarbeiten, um mit dieser Art von Situation richtig umzugehen - oder zumindest würde ich dieses Problem durch unseren Bug-Tracker melden > (Ich bin mir nicht sicher, welche Priorität ich zuweisen würde, aber trotzdem würde das Problem irgendwo protokolliert werden und jemand wird es irgendwann korrigieren, wenn es kein Problem mit höherer Priorität gibt) .
Ich würde es zurückschicken und ich mag die Frage.
Die gesamte Überprüfung ist teilweise subjektiv. Die Kriterien sollten auf einer Reihe von Faktoren basieren.
Funktioniert es.
Erfüllt es angemessene Erwartungen hinsichtlich Leistung, Wartungsfreundlichkeit, Benutzerfreundlichkeit und Skalierbarkeit
Obwohl ich dieses spezielle Konstrukt noch nicht getestet habe - ich vermute, dass (wie Sie) dieser Code Ihrem SQL Server schreckliche Dinge zufügen wird. Damit werden Leistung und Skalierbarkeit in Frage gestellt.
Ich würde fragen, warum Bind-Variablen nicht verwendet werden (es sei denn, es gibt einen guten Grund in bestimmten Fällen):
%Vor%Warum ist es nicht:
%Vor%