Performance verbessern?

[Audi]

Hallo,

hoffe Ihr könnt mir helfen.

Ich habe eine Access DB mit 4Tabellen mit insgesammt ca. 10000 Datensätzen.

Ich greife mit C# auf die Access DB zu und suche überall in den Tabellen nach einem bestimmten Begriff/Teilbegriff z.B USB, dann werden alle Artikel mit USB in meinem Programm angezeigt.

Mein Problem ist dass es so lange dauert, so ca. 7-10sec. also laaaam wie sau

Suche nach Verbesserungsvorschlägen die die Such Performance erhöhen.

Hier meine SQL-Abfrage in C#:

string kLagerListSelectStr = "SELECT DISTINCT ARTMENGE.ArtMengeNr, SARTIKEL.ArtName1, SARTIKEL.ArtName2, SARTIKEL.ArtZusInfo1, BESTDOK.BestDocName1,"

+ " ARTLIEF.ArtLiefBestellNr, ARTLIEF.ArtLiefEKPreis, SARTIKEL.ArtZusInfo2, SARTIKEL.ArtZusInfo4, SARTIKEL.ArtMatchcode"

+ " FROM ((ARTMENGE LEFT JOIN ARTLIEF ON ARTMENGE.ArtMengeNr = ARTLIEF.ArtLiefArtNr)"

+ "LEFT JOIN BESTDOK ON ARTLIEF.ArtLiefLiefNr = BESTDOK.BestDocLiefNr) LEFT JOIN SARTIKEL ON ARTMENGE.ArtMengeNr = SARTIKEL.ArtNr"

+ " WHERE ARTMENGE.ArtMengeNr LIKE '%" + suchStr  

+ "%' OR SARTIKEL.ArtName1 LIKE '%" + suchStr

+ "%' OR SARTIKEL.ArtName2 LIKE '%" + suchStr  

+ "%' OR SARTIKEL.ArtZusInfo1 LIKE '%" + suchStr 

+ "%' OR BESTDOK.BestDocName1 LIKE '%" + suchStr 

+ "%' OR ARTLIEF.ArtLiefBestellNr LIKE '%" + suchStr 

+ "%' OR ARTLIEF.ArtLiefEKPreis LIKE '%" + suchStr 

+ "%' OR SARTIKEL.ArtZusInfo2 LIKE '%" + suchStr 

+ "%' OR SARTIKEL.ArtZusInfo4 LIKE '%" + suchStr 

+ "%' OR SARTIKEL.ArtMatchcode LIKE '%" + suchStr 

+ "%'";

[perdian]

Mein Problem ist dass es so lange dauert, so ca. 7-10sec. also laaaam wie sau

Das verwundert nicht. LIKE-Abfragen sind immer potentielle Kandiaten für länger dauernde Datenbankabfragen. Wenn dann (wie bei dir) noch mehrere zusammenkommen wirds noch schöner.

Bevor wir allerdings in die Details gehen: Existiert ein Index auf den Spalten, die in den JOINs und in der WHERE-Klausel angegeben sind?

[dbwizard]

Das verwundert nicht. LIKE-Abfragen sind immer potentielle Kandiaten für länger dauernde Datenbankabfragen. Wenn dann (wie bei dir) noch mehrere zusammenkommen wirds noch schöner.

Bevor wir allerdings in die Details gehen: Existiert ein Index auf den Spalten, die in den JOINs und in der WHERE-Klausel angegeben sind?

...wobei ein index bei einer LIKE '%xxxx' Abfrage auch nichts nützen wird....

Gruss

[Audi]

nein kein Index vorhanden, was bedeutet ein Index bei einer DB?

[dbwizard]

nein kein Index vorhanden, was bedeutet ein Index bei einer DB?

hallo,

index :

Datenbankindex ? Wikipedia

Gruss

[perdian]

...wobei ein index bei einer LIKE '%xxxx' Abfrage auch nichts nützen wird....

Ich bin kein Datenbankimplementierungsspezialist aber spontan würde ich mal sagen, dass wenn zufällig LIKE direkt mit dem Inhalt matcht erfasst sowas ein Index auch. Aber gut, qualifizierte Kaffeesatzleserei ;-)

was bedeutet ein Index bei einer DB?

Wieso entwickelst du Datenbankanwendungen, wenn du dich nicht einmal mit den Grundlagen auskennst, wie eine Datenbank überhaupt aufgebaut ist?

[dr.dimitri]

Ich bin kein Datenbankimplementierungsspezialist aber spontan würde ich mal sagen, dass wenn zufällig LIKE direkt mit dem Inhalt matcht erfasst sowas ein Index auch. Aber gut, qualifizierte Kaffeesatzleserei ;-)

Bei einem LIKE 'xyz%' kann ein Index verwendet werden bei einem LIKE '%xyz' nicht (theoretisch kann er schon verwendet werden, nur müsste die DB den ganzen Index durchsuchen und in diesem fall ist ein Full Tablescan deutlich schneller.

Dim

[dbwizard]

Ich bin kein Datenbankimplementierungsspezialist aber spontan würde ich mal sagen, dass wenn zufällig LIKE direkt mit dem Inhalt matcht erfasst sowas ein Index auch. Aber gut, qualifizierte Kaffeesatzleserei ;-)

- nein, tut er nicht, wenn % am Anfang des Attributes steht. Wie soll er auch ?

(Beispiel abgeändert...)

Select mit [=]


SELECT a.identity_id

  FROM app_identity a

  WHERE NAME = 'Somename'


Plan :


SELECT STATEMENT  CHOOSE

   Cost: 6  Bytes: 45  Cardinality: 

3  Partition #: 0  		

2 TABLE ACCESS BY INDEX ROWID APP_IDENTITY 

    Cost: 6  Bytes: 45  Cardinality: 

3  Partition #: 0  	

1 INDEX RANGE SCAN IDENTITY_NAME_IDX 

    Cost: 3  Bytes: 0  Cardinality: 3  Partition #: 0 


Select mit LIKE:


SELECT a.identity_id

  FROM app_identity a

  WHERE NAME LIKE '%Somename'


Plan

SELECT STATEMENT  CHOOSE

  Cost: 521  Bytes: 240'870  Cardinality: 16'058  Partition #: 0  	

1 TABLE ACCESS FULL APP_IDENTITY 

  Cost: 521  Bytes: 240'870  Cardinality: 16'058  Partition #: 0  

Gruss

[dr.dimitri]

SELECT STATEMENT  CHOOSE

Was hast Du denn da für ne alte Version?

[dbwizard]

SELECT STATEMENT  CHOOSE

Was hast Du denn da für ne alte Version?

- Ich bin auch ne alte Version, also passt's zu mir :-).

Ist der Plan aus den SQL Navigator gegen ne 9er DB. Normalerweise trace ich die Sachen lieber, aber so auf die Schnelle....

Gruss

[Audi]

ok ich weiß jetzt:

- %LIKE Befehle lansam

- Ein Index nicht viel bringt bei einem LIKE

Wie kann ich z.B das %LIKE umgehen?

Wie könnte ich die Abfrage gestalten (siehe oben), damit dass schneller geht?

[perdian]

Wie kann ich z.B das %LIKE umgehen?

Na einfach nicht verwenden.

Eine Möglichkeit wäre ein externer Suchindex, der die Komplexität der Suche aus der Datenbank heraushält. Anbieter dafür gibt's genügend auf dem Markt, allerdings geht einem dann natürlich die Flexibilität verloren sofort auf Änderungen innerhalb der Datenbank zu reagieren.

But nothing comes for free! ;-)

[Audi]

Na einfach nicht verwenden.

Eine Möglichkeit wäre ein externer Suchindex, der die Komplexität der Suche aus der Datenbank heraushält. Anbieter dafür gibt's genügend auf dem Markt, allerdings geht einem dann natürlich die Flexibilität verloren sofort auf Änderungen innerhalb der Datenbank zu reagieren.

But nothing comes for free! ;-)

ja ok, wenn ich die %LIKE Befehle nicht verwende, wie soll ich dann die Artikel mit einem Stichwort suchen?

z.B

Suche: usb

Ergebnis der Suche: USB Kabel, USB HUB, USB irgendwas usw.

[Audi]

nochwas vergessen, ich suche mit Hilfe von C# in der Access DB.

Hier die Zugriffsfunktion

string connectionString = @"Provider=Microsoft.Jet.OLEDB.4.0;Data Source=" + path;

[perdian]

ja ok, wenn ich die %LIKE Befehle nicht verwende, wie soll ich dann die Artikel mit einem Stichwort suchen?

Du solltest vielleicht mein Posting komplett lesen - da stand etwas von externem Suchindex. Oder als Alternative eine Keyword-Tabelle.

[dr.dimitri]

Für solche Anforderungen gibt es Volltextindizes. Damit findest Du bei einer Suche nach Meier z.B. auch einen Mayer oder Maier. Ich weiß nicht ob Access das bietet aber das ist eben dann eine der vielen Einschränkungen die man hinnehmen muss, wenn man damit arbeitet.

Wenn es sich nicht nur um eine Übungsaufgabe sondern um ein echtes Projekt handelt, würde ich sowieso empfehlen von Access abstand zu nehmen und direkt auf eine richtige DB umzuschwenken. Beispiele wären hier z.B. PostgreSql oder die kostenlose Oracle XE Edition.

Dim

[Audi]

Wenn es sich nicht nur um eine Übungsaufgabe sondern um ein echtes Projekt handelt, würde ich sowieso empfehlen von Access abstand zu nehmen und direkt auf eine richtige DB umzuschwenken. Beispiele wären hier z.B. PostgreSql oder die kostenlose Oracle XE Edition.

Dim

Es ist ein echtes Firmeninternes Projekt, leider haben wir vor Jahren auf Access aufgebaut, können jetzt nicht einfach so mal wecheln...

Die suche soll also in Access über eine C# Oberfläche erfolgen.

[perdian]

Es ist ein echtes Firmeninternes Projekt, leider haben wir vor Jahren auf Access aufgebaut, können jetzt nicht einfach so mal wecheln...

Dann muss man sich überlegen was man nun wirklich möchte. Mit viel Brimborium und einer Menge Aufwand bekommt man sicherlich sowas auch in Excel verwurschtelt. Die Frage ist, ob die Anforderung nicht dertig bestimmend ist, dass man mann feststellt "Access ist nicht das richtige Werkzeug hierfür" und es vernünftig neu implementiert.

[Audi]

Dann muss man sich überlegen was man nun wirklich möchte. Mit viel Brimborium und einer Menge Aufwand bekommt man sicherlich sowas auch in Excel verwurschtelt. Die Frage ist, ob die Anforderung nicht dertig bestimmend ist, dass man mann feststellt "Access ist nicht das richtige Werkzeug hierfür" und es vernünftig neu implementiert.

Habe schon vor einiger Zeit mit meinem Chef darüber gesprochen, er meinte wir wechseln nicht.

Ich bin ja noch Lehrling und da spielt das Thema Geld nicht die entscheidende Rolle, mein Chef sieht die Sache so, wenn es irgendwie möglich ist, die Suche in der Access DB schneller zu machen soll ich es machen, auch wenn es 1Monat dauert, ist egal! wenn es keine möglichkeit gibt, soll ich am Projekt weitermachen und den Suchalgorithmus so belassen wie er ist.

Die Datenbank selbst ist auch nur read only (fürs Programm), spielt das eine Rolle, denke nicht, oder?

[Audi]

Es kommt erschwerend hinzu dass nach Art.Nr, Art.Menge, Beschreibung, Lieferanten Bestell.Nr, Lagerort usw. gesucht werden kann,

also verschiedene Spalten durchsucht werden müssen.

[perdian]

Ich bin ja noch Lehrling und da spielt das Thema Geld nicht die entscheidende Rolle, mein Chef sieht die Sache so, wenn es irgendwie möglich ist, die Suche in der Access DB schneller zu machen soll ich es machen, auch wenn es 1Monat dauert, ist egal! wenn es keine möglichkeit gibt, soll ich am Projekt weitermachen und den Suchalgorithmus so belassen wie er ist.

Na dann stell ihm doch die Alternativen vor. Erkläre ihm, was du bereits herausgefunden hast und was für alternative Möglichkeiten es noch gibt. Endlos wird er dich wohl auch nicht daran arbeiten lassen wollen, von daher: Wer begründet, der überzeugt. Leg hm die Tatsachen so auf den Tisch wie sie sind und lass ihn entscheiden, welchen Weg er weitergehen möchte.

Die Datenbank selbst ist auch nur read only (fürs Programm), spielt das eine Rolle, denke nicht, oder?

Nein. Warum sollte es?