Zitat Zitat von Rincewind
So etwas kann man übrigens auch über ein normales (nicht on-the-fly) SQL lösen..


Select a, b, c from datei where

(:EingabeA = ' ' or :EingabeA = a) and
(:EingabeB = ' ' or :EingabeB = b) and
(:EingabeC = ' ' or :EingabeC = c)


Damit hast du immer denselben Zugriffsweg und die angenehmen Performancevorteile.

Damit habe ich die prepare Statements bei mir auf flexible Sortierung bzw flexible Feldauswahl eingeschränkt (was einen erheblichen Performancegewinn bringt)

Schönen Gruß
Rince
So etwas hat mit performanten SQL nichts mehr zu tun. Diese Logik führt dazu, das die Abfrage immer in einem kompletten Table-Scan endet.

Ich habe das einmal Beispielhaft an eine Datei mit 2.1 Mio Sätzen durchgeführt. In der WHERE-Bedingung stehen zwei Parameter, einmal direkt angegeben und einmal mit der geklammerten OR-Angabe, Index über diese beiden Werte vorhanden.
Zeiten aus dem VE:
195234 Mikrosekunden Direktangabe
12920528 Mikrosekungen geklammerte OR-Angabe.

Mit solchen OR-Abfrage kann der Optimizer nichts mehr anfangen. Da ist eine prepare-Abfrage immer vorzuziehen. Statisches SQL macht nur bei bekannter Parameter-Anzahl Sinn.

Bei dem Problem von sim wäre es besser, für gängige Abfragefelder Indizies aufzubauen. Nicht so häufig benutzte Felder sollten separat mit dem Hinweis auf die lange Ausführdauer aufgeführt werden (eventuell separatem Window über Funktionstaste).

Gruß
M.Withake