Suche unter Verwendung von UPPER() beschleunigen

[Frank Schäfer]

Hallo,

ich verwende in meinem Projekt eine InterBase-Datenbank auf die ich mit den IBX-Komponenten zugreife.

In einzelnen Fällen wäre es schön zu leichteren Suche nach Feldinhalten nicht auf die Schreibweise achten zu müssen. Bisher versuche ich soetwas mit UPPER(). Also z. B.

select * from "TABELLE" where (UPPER("FELD") = 'ABC')

Bei einer Solchen Suche kann InterBase allerdings einen vorhandenen Index auf "Feld" nicht mehr nutzen und wird dadurch ziemlich langsam. Gibt es eine Möglichkeit solche Abfragen zu beschleunigen, z. B. einen Zusätzlichen Index auf UPPER("FELD") anzulegen?

Vielen Dank für eure Hilfe.

Gruß, Frank.

[Andreas Kosch]

Hallo,

in derartigen Fällen gibt es verschiedene Möglichkeiten:

a) Optimizer "überlisten": <br>
Wenn zusätzlich eine "unnötige" Einschränkung definiert wird, greift der InterBase u.U. doch auf den Index zurück.
<pre>
select * from "TABELLE"
where (UPPER("FELD") = 'ABC')
AND FELD > 'A'
</pre>

b) Separate Spalte der Tabelle: <br>
Für die UPPER-Werte wird eine eigene Spalte in der Tabelle hinzugefügt, deren Wert innerhalb eines TRIGGERS beim INSERT+UPDATE gefüllt wird. Auf diese Spalte wird dann ein INDEX gelegt

[Frank Schäfer]

Hallo Andreas,

vielen Dank für deine Antwort. Eigentlich hatte ich ja gedacht, du kramst jetzt eine versteckte Funktion zur Erstellung eines "UPPER"-Indexes heraus oder schreibst wenigstens wie man mit IB einen Index auf ein "COMPUTED"-Feld anlegt - aber heut' is' wohl noch nicht Weihnachten ;-) .

Vorschlag a) bringt in meinem konkreten Fall leider nichts, Vorschlag b) bleibt wohl die einzige Möglichkeit, wobei sich durch den erhöhten Platzbedarf die Erleichterung wohl nur in besonders harten Fällen anbietet.

Gruß, Fran

[Andreas Kosch]

Hallo,

ein berechnetes Feld wird nur bei der Ausführung der SELECT-Anweisung berechnet, das Feld ist jedoch physisch nicht vorhanden. Und da die Daten erst dann vorliegen, wenn die Ergebnismenge fertig ist, macht es auch keinen Sinn, danach (!) einen Index dafür im Arbeitsspeicher zu erzeugen (aus diesem Grund steht diese Option erst gar nicht zur Verfügung)

[Gesine Kuhlmann]

Hallo,

1)
Die logische Konsequenz wäre doch in der DB überhaupt nur Großbuchstaben zuzulassen.

2)
Sollen auch Kleinbuchstaben verwendet werden und man will davon abweichende ( also ignoriere Groß/Kleinschribung ) Suchauskriterien verwenden, so muss man einfach damit leben, dass eine Umwandlungsfunktion im Suchausdruck die Ausführungsgeschwindigkeit drückt.

3)
Wie richtig bemerkt ist nicht Weihnachten und eine SQL-Datenbank kein Wunschkonzert.

Gruß Gesine

P.S.

Der Vorschlag b) von Andreas, eine zusätzliche Spalte anzulegen, die automatisch mit Großbuchstaben gefüllt wird, eliminiert übrigens den Geschwindigkeitseinbruch. Zusätzlicher Speicherdarf darf bei den heutigen MB-Preisen für Festplatten aber wohl zu verschmerzen sein