performance -> SQL-Optimierung

[Wolfgang Steinhauer]

Hallo Michael,

> Du hast landkreis und ortschaften als Fulltext Key deklariert, das ist
zwar
> nett, klappt aber nur wenn man MATCH (anstatt LIKE) verwendet, außerdem
> hilft ein Fulltext Key überhaupt nix, wenn man mitten in einem Wort suchen
> will.

Wie eben schon gesagt: Experimente in alle Richtungen......

> Zum Thema Landkreis, Ortschaften:
> Wenn diese wirkliche nicht mit like "$wert%" anstatt "%$wert%" suchbar
sind
> wäre es evtl sinnvoll diese in eine extra Tabelle zu werfen. Dann muß bei
> der Erfassung je Land/Bundesland/Kreis/Ort eine Liste der verfügbaren
Werte
> angezeigt werden mit der Möglichkeit Länder/Orte etc. hinzuzufügen. Macht
> die Programmierung dort natürlich komplizierter.

Das steht auch wieder in keinem Verhaeltnis zum Nutzen....
Meiner Meinung nach....
Dann muss der User eben alle 100 Eintraege durchgehen ob wer in seinem
Landkreis dabei ist....
Oder: Er muss eben die lange Laufzeit in Kauf nehmen, wenn er solch eine
komfortable Suche heben moechte....

> Wichtig ist es natürlich mit den Abfrage-Kriterien auf = und like
"<wert>%"
> die indizierbar sind, zunächst die Ergebnismenge möglichst gut
> einzuschränken bevor die DB dann mit dem "Tablescan" für die like
"%<wert>%"
> Felder beginnt.

Geht leider nicht, weil meist mehere Landkreise/Orte, durch Komma getrennt,
angegeben werden......

> Du verwendest z.B. art_id für die Einschränkung (ist integer, wieso setzt
Du
> das in Anführungszeichen?). Das ist ja schon evtl. ganz passabel wenn es
> viele verschiedene Arten (war mir doch so bei Insekten) gibt. Man könnte
> bundesland_id (wieso wieder die Anführungsstriche, ist doch auch eine
Zahl?)
> und art_id in einer Tabelle zu vereinen.

Nicht machbar weil 1:n Beziehung........
Ein Dienstleister kann in mehreren Bundeslaendern arbeiten kann auch mehrere
(1:n) Tiere bearbeiten......
Deshalb MUSS die Abfrage ueber drei Tables sein......

Okay, bliebe noch temp-Tables zu erzeugen.....
Wie aber soll das dann wieder gehen, wenn z.B. 100 User gleichzeitig auf dei
DB zugreifen....
Fuer jeden einen eigenen temp-Table erzeugen ?????
Abfrage der session-ID und die als Namen des Tables hernehmen.... ??

Wie steht ea dann aber wieder mit der performance ???? Speicherplatz ???

Weiss nicht, erscheint mir sehr umstaendlich.....

Oder doch alles ueber PostgeSQL realisieren....

> In diesem Falle könnte man einen gemeinsamen Schlüssel auf art_id und
> bundesland_id setzen (wenn beide in einer Tabelle zusammenführbar wären).

Waere einfach zu schoen um wahr zu sein....
Ist aber leider nicht moeglich....

Liebe Gruesse,
wolf

-- 
Infos zur Mailingliste, zur Teilnahme und zum An- und Abmelden unter
-->>  http://www.4t2.com/mysql