SQL Schlüsselwort contains

[dschroeder]

Hallo Forum,

ich bin gerade auf das SQL-Schlüsselwort CONTAINS gestoßen. Damit soll man Textinhalte finden können. Das SQL-Handbuch sagt dazu, dass das nur funktioniert, wenn die zu durchsuchende Spalte in der Datei auf einem "textindex" bzw. "text search index" basiert. Weiß jemand, wie man so einen Index erstellt? Benötigt man dazu OMNIFIND? Zur Zeit suchen wir mit like. Aber das ist manchmal ganz schön langsam. Insbesondere, weil wir Groß/Kleinschreibung ignorieren wollen und deshalb zusätzlich lower anwenden.

Kann jemand etwas zu contains bzw. text search index sagen?

Vielen Dank in Voraus,
Dieter

[B.Hauser]

Du benötigst zum einen Omnifind Text Search und musst spezielle Text Idices anlegen.

Hier ein brandaktueller Artikel von Kent Milligan (allerdings weiß ich nicht, ob dieser Artikel für jeden zugänglich ist, ausprobieren!)
Search Your System with IBM's OmniFind
Index and search IFS and spool file objects
Date Posted: June 28, 2012 06:00 AM
Author: Kent Milligan


Birgitta

[dschroeder]

Hallo Birgitta,

vielen Dank. Ich denke, wir werden und das OMNIFIND mal besorgen. Ich habe aber noch eine Frage. Ich habe gerade festgestellt, dass man Indizes auch mit Funktionen belegen kann. (z.B. create index index1 on Adressen(lower(name1)) Wenn man das macht, müsste eine Suche nach "name like '%meier%' doch eigentlich schneller gehen als unsere übliche Suche "lower(name) like '%meier%'". Falls das so ist: Woher weiß ich denn, welchen "lower"-Indizes ich erstellen soll. Der Index-Advisor gibt so etwas ja nicht an. Und außerdem. Wenn ich wirklich mal nach "Meier" (also inkl. Groß und Kleinbuchstaben) suchen will: Wie sage ich der Suchanfrage denn, dass er dann nicht den "lower"-Index verwenden soll?

Dieter

[B.Hauser]

Die Geschichte mit den derived und sparsed Indices (d.h. neue Spalten und Where-Bedingungen) ist noch nicht völlig ausgereift.

In Release 6.1 waren diese Indices fast ausschließlich für die Verwendung mit Native I/O (anstatt DDS beschriebenen logischen Dateien) gedacht.
In einigen wenigen Fällen konnten vom Optimizer Indices verwendet werden, in denen die Where-Bedingungen genau übereinstimmen, d.h. when im SQL Statement tatsächlich WHERE Lower(Name) = oder like angegeben wurde. Der Index wurde und wird nicht verwendet wenn Name = oder like angegeben ist. Er wird auch nicht verwendet, wenn Upper(Name) = oder like angegeben ist.

Nach und nach werden von IBM weitere Regeln unter denen derived oder sparsed Indices vom Optimizer verwendet werden können eingeführt.

Birgitta

[dschroeder]

Vielen Dank.

Dieter

[Pikachu]

Probier mal mit Sortierfolge *LANGIDSHR:

1) Logische Datei mit CRTLF FILE(Bibliothek/Datei) SRTSEQ(*LANGIDSHR) anlegen

2) STRSQL SRTSEQ(*LANGIDSHR)

3) SELECT Name FROM Bibliothek/Datei WHERE Name LIKE '%Meier%'

[dschroeder]

Wie kann ich das denn im RPG (embedded sql) verwenden? Irgenwie müsste ich dem SQL dann ja sagen, dass die Sortierfolge verwenden soll.

Probier mal mit Sortierfolge *LANGIDSHR:

1) Logische Datei mit CRTLF FILE(Bibliothek/Datei) SRTSEQ(*LANGIDSHR) anlegen

2) STRSQL SRTSEQ(*LANGIDSHR)

3) SELECT Name FROM Bibliothek/Datei WHERE Name LIKE '%Meier%'

[Fuerchau]

Hierzu betrachte mal den Like:

Like '%xxx%' => Kein Index möglich!
Like 'xxx%' => Index möglich

Der Grund ist eben, dass ein Index ja nicht über jeden Teilschlüssel (Substring) erstellt wird sondern über den gesamten Wert.
Ein Like '%...' erzwingt immer eine Tablescan, solange nicht andere Felder in der Whereklausel Indexverwendungen ermöglichen.

Wenn man ähnlich klingende Schlüssel sucht, kann man SOUNDEX() verwenden, wobei hier ein ggf. vorhandener berechneter Index verwendet werden kann:

where soundex(Namensfeld) = soundex('Meier')

in diesem Fall werden Meier, aber auch Meyer o.ä. geliefert.

Apropo embedded SQL:
exec sql set options ....

[dschroeder]

Klar, dass er nicht binär suchen kann. Aber wenn ein Index so aufgebaut wäre, dass alle Zeichen des Namens in Kleinbuchstaben gespeichert sind, könnte er den Tablescan dann ja auf dem Index machen, anstatt das echte Dateifeld zu nehmen. Das "echte" Dateifeld müsste er ja immer erst in Kleinbuchstaben umwandeln, bevor er die like-Suche auf dem feld macht.

Hierzu betrachte mal den Like:

Like '%xxx%' => Kein Index möglich!
Like 'xxx%' => Index möglich

Der Grund ist eben, dass ein Index ja nicht über jeden Teilschlüssel (Substring) erstellt wird sondern über den gesamten Wert.
Ein Like '%...' erzwingt immer eine Tablescan, solange nicht andere Felder in der Whereklausel Indexverwendungen ermöglichen.

Wenn man ähnlich klingende Schlüssel sucht, kann man SOUNDEX() verwenden, wobei hier ein ggf. vorhandener berechneter Index verwendet werden kann:

where soundex(Namensfeld) = soundex('Meier')

in diesem Fall werden Meier, aber auch Meyer o.ä. geliefert.

Apropo embedded SQL:
exec sql set options ....

[Fuerchau]

Ja und nein.
Ein Indexonly-Zugriff erfolgt ausschließlich, wenn auch nur Felder im Select verwendet werden, die im Index vorkommen.

Also ein
"select name where name like '%xxx%'"
mag dann schneller sein.

Für den Indexonly-Zugriff wäre ggf. folgender Select performant, kann ich aber nicht versprechen:

with
xName as (
select name
from mytable
where name like '%xxx%')

select ....
from mytable x
inner join xName on x.name = xName.Name
where ...

[Pikachu]

Siehe hier: http://newsolutions.de/forum-systemi...html#post57786.

Alternativ kannst du die Sortierfolge auch im CRTSQLRPGI angeben.

Wie kann ich das denn im RPG (embedded sql) verwenden? Irgenwie müsste ich dem SQL dann ja sagen, dass die Sortierfolge verwenden soll.

[Fuerchau]

Da der Default auf *JOB verweist, kann man das ebenso dynamisch per CHGJOB erreichen, halt nur mit dem Nachteil, dass dies alle Programme des Job's betrifft.