MySQL: Suche, wie am besten?

[muenzchen]

Hallo,

Ich habe eine MySQL Datenbank mit bisher ca. 10.000 Einträgen. Es werden sicher einmal weit über 100.000 werden.
Ich möchte jetzt eine Suche einbauen (über PHP), allerdings weiß ich nicht genau, wie ich das am resourcensparendsten anstelle.
Zuerst ist mir natürlich gleich LIKE eingefallen. Ist das ok, eine Suche mit LIKE aufzubauen?

Des weiteren habe ich schon öfter zb. in Foren gesehen, dass Suchergebnisse in der Datenbank gespeichert werden um schneller abgerufen werden zu können. Allerdings verstehe ich nicht ganz wie das funktionieren soll, wenn sich sowohl die bestehenden Einträge ändern können als auch neue Einträge hinzukommen.

Kennt sich jemand ein wenig damit aus?

MfG, muenzchen

[TG]

Des weiteren habe ich schon öfter zb. in Foren gesehen, dass Suchergebnisse in der Datenbank gespeichert werden um schneller abgerufen werden zu können. Allerdings verstehe ich nicht ganz wie das funktionieren soll, wenn sich sowohl die bestehenden Einträge ändern können als auch neue Einträge hinzukommen.

Ich kann mir nicht vorstellen, dass jemand Suchergebnisse speichert. Das wäre ja wie du schon sagst nur eine Momentaufnahme, es sei denn man möchte z.B. eine Übersicht wie "neu angemeldete User 2003" oder ähnliches bereitsstellen - dann würde das durchaus Sinn machen.

In der Regel werden aber nicht die Suchergenisse, sondern die Suchabfrage an sich (der Abfrage-String) gespeichert, der wenn man ihn auswählt immer die aktuelle Datenbank abfragt.

[muenzchen]

Hallo,

Verstehe. Aber den Abfragestring zusammenzustellen bedeutet ja keinen großen Serveraufwand. Also ist das meiner Ansicht nach eher sinnlos. Oder habe ich da was falsch verstanden. Was ich jedenfalls meinte ist, dass Suchanfragen beim ersten Anfragen meistens länger brauchen, aber dann supischnell gehen. MAcht MySQL das selbst oder muss man da nachhelfen?
Und ist es bei so vielen Einträgen wirklich normal LIKE zu benutzen? Das dauert doch ewig oder?

MfG, muenzchen

[Daniela Koller]

Hi muenzchen

Was ich jedenfalls meinte ist, dass Suchanfragen beim ersten Anfragen meistens länger brauchen, aber dann supischnell gehen. MAcht MySQL das selbst oder muss man da nachhelfen?

Das machen DBMS von sich aus ohne das du nachhelfen musst.

Und ist es bei so vielen Einträgen wirklich normal LIKE zu benutzen? Das dauert doch ewig oder?

LIKE ansich ist nicht böse. Böse wird es erst, wenn LIKE '%...' oder LIKE '_...' benutzt wird da dann kein Index mehr benutzt werden kann.

Gruss Daniela

[Andreas-Lindig]

Hallo Daniela,

Was ich jedenfalls meinte ist, dass Suchanfragen beim ersten Anfragen meistens länger brauchen, aber dann supischnell gehen. MAcht MySQL das selbst oder muss man da nachhelfen?

Das machen DBMS von sich aus ohne das du nachhelfen musst.

was heißt denn 'zweites Mal' oder 'wiederholte Anfrage'? Ich meine: wenn ich heute mein MySQL frage Welche Einträge gibt es vom User mit der ID 42 (WHERE userID=42) und morgen wieder frage, ist das doch wohl nicht mehr gespeichert oder? Wenn aber das Zwischenspeichern z.B. während ein und derselben DB-Verbindung geschieht: welche Anwendung gibt es, da zweimal die gleiche Frage abzusetzen? Mir ist das noch nicht passiert.

LIKE ansich ist nicht böse. Böse wird es erst, wenn LIKE '%...' oder LIKE '_...' benutzt wird da dann kein Index mehr benutzt werden kann.

ach, und LIKE '...%' benutzt den Index, soweit vorhanden?

Gruß, Andreas

[Christian Seiler]

Hallo Andreas,

ach, und LIKE '...%' benutzt den Index, soweit vorhanden?

AFAIK: Ja.

Viele Grüße,
Christian

[Christian Kruse]

Hallo Andreas,

LIKE ansich ist nicht böse. Böse wird es erst, wenn LIKE '%...' oder LIKE '_...' benutzt
wird da dann kein Index mehr benutzt werden kann.

ach, und LIKE '...%' benutzt den Index, soweit vorhanden?

Ja. Du musst dir den Index wie einen Baum vorstellen, z. B. so:

ABCD
                         /       \                        AAD       ACC
                      /  \      /  \                     AAB  AAE  ACA  ACD

Stellst du jetzt eine Abfrage nach z. B. 'AAE', so kann die Datenbank den Pfad von ABCD über
AAD nach AAE gehen, da AAE kleiner als ABCD aber größer als AAD ist.

Fragst du nun nach 'AA%', so sieht die Datenbank, dass AA kleiner als ABCD ist. Deshalb
können jegliche in Frage kommenden Ergebnisse nur im linken Teilbaum enthalten sein. Der
nächste Knoten ist AAD, auf den das Muster 'AA%' ja bereits passt. Also ist der Teilbaum
ab AAD die Ergebnismenge.

So oder so ähnlich funktioniert das in Datenbanken, nur dass Datenbanken oft B-Bäume statt
Binär-Bäumen nutzen. B-Bäume sind Baum-Strukturen, die mehr als zwei Knoten haben können.

Grüße,
 CK

[Christian Kruse]

Hallo Andreas nochmal,

ABCD
                         /       \                        AAD       ACC
                      /  \      /  \                     AAB  AAE  ACA  ACD

Was ich vergessen habe zu erwähnen: eine Suche nach '%C' kann nicht über den Index laufen, da
dort prinzipiell alle Datensätze in Frage kommen. Hier kann nicht anhand einer Vorauswahl die
Ergebnismenge reduziert werden, hier muss wirklich jeder einzelne Datensatz geprüft werden.

Grüße,
 CK

[Andreas-Lindig]

Dankeschön, war sehr verständlich.

Gruß, Andreas