FB: Prepared Query mit In-Statement ?

[hoika]

Hallo,
die 100 habe ich mal so hingeschrieben.
Es können auch mehr sein.
Die betreffende Query hat noch keinen Outer Join,
der macht das Umbauen in eine einzige Query noch viel langsamer.

Das Containing klingt doch schon mal gut.
Aber das kann doch nicht stimmen,
ich habe z.B. 12 und 12B in der Datenbank,
suche ich jetzt über Containg ;12;, wird auch das 12B gefunden, richtig?

Das könnte ich aber über eine nachträgliches If beim Durchlaufen der Query lösen.

Ein Full Table Scan ist es nicht, weil Field1 indiziert ist.

PS:
Der Code ist alt. Ich versuche ihn zu Optimieren,
ohne alles neu schreiben zu müssen.

[p80286]

Zitat von hoika:

Der Code ist alt. Ich versuche ihn zu Optimieren,
ohne alles neu schreiben zu müssen.

Der Versuch ist nicht strafbar, aber trotzdem hätte ich ein schlechtes Gefühl dabei. Auch mich macht der mehrfache Aufruf erst einmal stutzig. Du solltest vielleicht eine Ebene höher ansetzen und Deine Abfragen hinterfragen, statt an ihrer Syntax zu basteln.

Gruß
K-H

[hoika]

Hallo,
das Problem ist nicht die Abfrage, sondern der dahinterliegende Code.
Da habe ich einfach keine Lust, den zu ändern.

Der Mehrfachaufruf kommt halt von der prozeduralen Rangehensweise:
- ermittle Anzahl der Gruppenmitglieder
- ermittle pro Gruppenmitglied diverse Daten (for-Schleife)
je nach Art des Mitgliedes sind es andere Daten

[Delphi.Narium]

Verzichte auf das Prepare und baue das SQL jeweils zusammen.

Die Verwendung von IN im Zusammenhang mit Parametern ist eher grenzwertig, insbesondere dann, wenn die Menge der Werte innerhalb des IN von Statement zu Statement variiert.

[jobo]

Zitat von hoika:

das Problem ist nicht die Abfrage, sondern der dahinterliegende Code.
Da habe ich einfach keine Lust, den zu ändern.

Der Mehrfachaufruf kommt halt von der prozeduralen Rangehensweise:
- ermittle Anzahl der Gruppenmitglieder
- ermittle pro Gruppenmitglied diverse Daten (for-Schleife)
je nach Art des Mitgliedes sind es andere Daten

Ich will nicht nerven, aber mein Geschwafel weiter vorne dreht sich genau darum. Die Idee ist die Iteration im Code zu entfernen bzw. zurückzubauen, Ermittlung der Anzahl und Aktivitäten der Mitglieder in einem "großen" Statement.
Die DB würde sich freuen, vielleicht sogar der Codeleser und Versteher.

SQL ist genau dafür geschaffen, Daten zu verknüpfen und zu transformieren. Für eine prozedurale Lösung- zur Datenzusammenstellung wohlgemerkt- gibt es nur selten Argumente.
Eine Fall basierte Business Logik, die anhand der Daten dann unterschiedliche Aktivitäten(! nicht Selektionen) startet, ist im Client gut aufgehoben. (Geht auch anders, ist aber hier nicht das Thema)
Guten Rutsch!

[IBExpert]

Zitat von hoika:

ich habe z.B. 12 und 12B in der Datenbank,
suche ich jetzt über Containg ;12;, wird auch das 12B gefunden, richtig?

nein, wenn sich das auf meine Lösung bezieht, weil um den wert aus der Tabelle, mit dem
im parameter gesucht wird, ja immer ein Semikolon davor und dahinter dynamisch ergänzt ist

';12B;13;13A;' containing ';12;' ist false

du musst deinen parameter sauber mit Trenner zusammenbauen

[hoika]

Hallo,
Jobs
ja, will ich aber nicht

Holger
dann verstehe ich das Containing nicht
Ah, auch das Select anpassen!

[hoika]

Hallo,
so, ich hatte jetzt mal Zeit, das Prepare nach Holgers Anleitung einzubauen.

Ergebnis:
nur minimale Verbesserung der Performance

Die Anzahl der Queries ist hier halt doch entscheidend.