[Gelöst] [CC] - SQL Abfrage Artikelsuche

Hi,

ich versuch gerade erste Schritte mit dem SQL Profiler, wir haben da einige NAV Abfragen die schon mal etwas länger dauern, da wollte ich mal schauen wo es hakelt und ob man da noch etwas optimieren kann.

Wenn die Benutzer im VK-Zeilen Feld "No.", ein Begriff eingeben, wird die "Artikelsuche" Funktion durchlaufen, die Reihenfolge ist (wenn ein Punkt zutrifft kommt eine Liste mit den Treffern, falls kein Treffer gefunden wird geht es zum nächsten Punkt):

1. Prüfen ob Artikel Nr mit Suchbegriff anfängt
2. Prüfen ob es Artikel referenzen zum eingegebenen Begriff gibt
3. Prüfen ob der Begriff im Feld Suchbegriff des Artikel vorkommt
4. Prüfen ob es eine Kreditoren Artikel Nr gibt welche mit dem Begriff anfängt

Am häufigsten läuft die Funktion im Punkt 3 (Suche nach Suchbegriff) , da könnte ich dann schonmal die Reihenfolge der zu durchlaufenden Abfragen ändern.

1. Suchbegriff durchsuchen
2. Art Nr
3 Referenz
4. Kred Art Nr

Der Filter ist Simple:

Code:

Text := '@*suchbegriff*'
Item.SETCURRENTKEY( "Search Description" );
Item.SETFILTER( "Search Description", '%1', Text );
IF Item.COUNT > 1 THEN BEGIN
   //Zeige Liste ...


Nun finde ich für die Durchsuchung des Suchbegriffs folgende SQL Anweisung:

Code:

"Search Description" LIKE '%FR[AÀÁÂÃÄÅ][NÑ]KF[UÙÚÛÜ]RT[EÈÉÊË]R%')

Dass im Falle von A alle Sonder A's gesucht werden scheint so ein SQL Ding zu sein?

Hat das Einfluss auf die Dauer der Abfrage? Falls Ja.
Kann man das ändern ?
Dass ein

Code:

"Search Description" LIKE '%FRANKFURTER%')

daraus wird...

Danke

Zuletzt geändert von elTorito am 24. März 2015 12:04, insgesamt 1-mal geändert.

Hast Du in der DB die Option 'Akzent beachten'?

Hast Du in der DB die Option 'Akzent beachten'?

Habe folgende Optionen bei Sortierung :

Sortierungstyp: SQL Sortierung.

Western-European dictionary sort order, code page 850, case sensitive, accent sensitive (41)
Sortierung überprüfen = Ja.
Binär = Nein
Groß-/Kleinschreibung beachten= Nein
Akzent beachten = Nein

Ich denke das Problem ist eher beim Filter mit dem führenden * zu suchen.
Muss die Suche den per default so sein?
Wir haben eine ähnliche Suche, jedoch müssen die Anwender den führenden Stern immer manuell und bewust eintippen.
Wir führen 90'000 Artikel und di Performance ist Top!

Gruss

Ich schätze mal das das COUNT deine Performance runterzieht. Mach mal bitte ein NOT ISEMPTY draus und versuchs nochmal.

gruß

Ich denke das Problem ist eher beim Filter mit dem führenden * zu suchen.
Muss die Suche den per default so sein?

Ja, muss so sein, die User geben auch Manuelle * ein, z.B.

ziegel*frankfu, ob der user nun Manuell ein * vorne ran hängt und hinten, oder ob die Progranmmierung das macht (bevor der Filter gesetzt wird) ist denke ich mal egal, wir haben an die 500 TSD Artikel, da wird man fast nur über Volltextsuche fündig , leider ändern sich bei uns auch schonmal von Woche zu Woche die Beschreibungen, deswegen ging ich hin und schreibe die Beschreibung 1 und 2 in das Feld Suchbegriff

Ich schätze mal das das COUNT deine Performance runterzieht. Mach mal bitte ein NOT ISEMPTY draus und versuchs nochmal.

Ja. Das ISEMPTY Scheint die Sache besser zu machen. Habe jetzt auch den Artikel hier gefunden (NAV Performance Optimierung SQL)

Von Duration 22 ms mit COUNT, die Artikelsuche Abfrage auf 1 ms reduziert mit ISEMPTY

Dann werde ich mich mal auf die Suche nach ein paar COUNT's machen

Danke für den Tipp

Wenn der Wert von COUNT nicht exakt stimmen muss, kannst du auch COUNTAPPROX verwenden. Es ist eine Näherung an den reellen Wert.
Aber merke, wenn die Verarbeitung nur in Abhängigkeit einer leeren Ergebnismenge steht, und der Rec danach nicht benutzt wird, dann ISEMPTY verwenden. Es spart dir eine SQL Abfrage (u.U. mit LIKE auf ein Textfeld, = worst case für SQL = table scan)

Wenn der Wert von COUNT nicht exakt stimmen muss, kannst du auch COUNTAPPROX verwenden. Es ist eine Näherung an den reellen Wert.
Aber merke, wenn die Verarbeitung nur in Abhängigkeit einer leeren Ergebnismenge steht, und der Rec danach nicht benutzt wird, dann ISEMPTY verwenden. Es spart dir eine SQL Abfrage (u.U. mit LIKE auf ein Textfeld, = worst case für SQL = table scan)

Hi,

danke, habe die Suchfunktion nun so umgemodelt dass gar nicht mehr COUNT = oder > 1 benutzt wird,
für das 1er Ergebnisse benutze ich GET

Code:

IF NOT Item.GET(Text) THEN BEGIN
   Item.SETFILTER( "Search Description", '%1', Text );
   IF NOT Item.ISEMPTY THEN BEGIN
     ItemList.LOOKUPMODE(TRUE);
     ...
....


COUNTAPPROX merke ich mir auch mal.

Ich muss das Thema mit der Optimierung mal vertiefen, wahrscheinlich auch gut für wenn wir mal auf RTC umsteigen?.