SQL: Performance LIKE

[martrip]

Verstehe. So langsam kommt Licht in die Sache

Werde einmal einen Index mit upper erstellen lassen und dann die Zugriffszeiten analysieren.

Im besten Fall wäre es gut, wenn beide den selben Index zeitgleich verwenden können.
Sollte das nicht gehen, ist es in diesem Fall nicht so tragisch, denn die Anwendung wird nicht sehr oft-, und von nur maximal 5 Usern, verwendet.

[Fuerchau]

Ich hoffe doch, dass das 32K-Feld als VARLEN definiert ist und Restblanks auch tatsächlich entfernt sind.
Auch das spart Suchzeit, da im Zweifel bei 32K ggf. weniger als 1% tatsächlich belegt ist.
Ein %SCAN (SQL macht da ja nichts anderes) geht nicht über die definierte sondern nur über die gefüllte Länge.

[martrip]

Feld ist als VARLEN(5000) definiert, da die meisten Einträge natürlich deutlich kürzer sind als 32k zeichen.

Habe jetzt einmal einen Index erstellt wo das lower() schon enthalten ist.
Hier werde ich aber noch ein rtrim() hinzu geben.

Ich denke dann sollte der Index seine maximale Wirkung für unsere Zwecke entfalten

[Fuerchau]

Allerdings nur, wenn die where-Klausel zum Index identisch ist.

[martrip]

Ah ok, wollte das eigentlich so machen, rtrim ist hier aber nicht zulässig.

create index stamdat.idx_termknpx on stamdat.termknpx(lower(rtrim(TKNTXT)))

Gut dann muss das lower reichen.

VARLEN ist auf 5000 gesetzt.

Gibt es eine andere Möglichkeit die Blanks direkt in der Datei zu entfernen?

[andreaspr@aon.at]

Update Tab Set spalte = rTrim(Spalte)

lg Andreas

[Fuerchau]

Die Programme, die die Daten erstellen sollten das allerdings auch tun!

[martrip]

Verstehe, werden wir beides noch machen.
Denn Index muss ich dann aber nicht neu erstellen nach dem Update oder?

[Fuerchau]

Ein Index wird parallel gepflegt.