Suchmaschine selber bauen

Der_Jan

Aktives Mitglied
Thread Starter
Dabei seit
06.01.2004
Beiträge
711
Reaktionspunkte
30
Ich träume von einer eigenen Suchmaschine für meine Homepage. Die Inhalte sind bereits vollständig in einer MySQL abgelegt, sollte also irgendwie möglich sein.

Hat hier jemand mit solchen "Träumen" Erfahrung und kann mir einen Ansatz anbieten, wie eine Suchabfrage in php aussehen kann?

Danke & Gruß
Der Jan
 
Naja, also um da eine genauere Aussage treffen zu können müsstest Du etwas von Deiner DB-Struktur erzählen.

Ganz generell: SELECT * FROM {tabelle} WHERE {feld} LIKE '%$suchwort%';

Bei mehreren Suchworten den Suchstring vorher mit explode(' ',$suchstring) zerstückeln und die SQL-Bedingung in einer Schleife zusammenbauen.

Den Query am besten noch mit LIMIT eingrenzen und Seitenzahlen-Links per PHP ausgeben. Die Links müssen dann wieder auf die gleiche Seite führen, den Suchstring und einen Startpunkt für das LIMIT enthalten.
 
dms schrieb:
Naja, also um da eine genauere Aussage treffen zu können müsstest Du etwas von Deiner DB-Struktur erzählen.

Ganz generell: SELECT * FROM {tabelle} WHERE {feld} LIKE '%$suchwort%';

Bei mehreren Suchworten den Suchstring vorher mit explode(' ',$suchstring) zerstückeln und die SQL-Bedingung in einer Schleife zusammenbauen.

Den Query am besten noch mit LIMIT eingrenzen und Seitenzahlen-Links per PHP ausgeben. Die Links müssen dann wieder auf die gleiche Seite führen, den Suchstring und einen Startpunkt für das LIMIT enthalten.

Eine Suche in der MySQL DB mit LIKE empfehle ich dir nicht!
Genau für soetwas gibt es den FULLTEXT Index. Also, mysql.com
und FULLTEXT suchen.

Gruß, Micha
 
Warum empfiehlst Du es nicht? Beides hat Vor- und Nachteile. Der Vorteil von einer Suche mit FULLTEXT/MATCH/AGAINST ist dass es etwas schneller ist (was aber bei kleinen Seiten nicht so sehr von Bedeutung ist) und die Relevanz direkt berechnet werden kann.
Der Vorteil von LIKE ist dass auch Teilworte gefunden werden. Per MATCH/AGAINST wird z.B. nicht "wort" innerhalb von "antwort" gefunden.
Beides hat natürlich seine Berechtigung.
 
dms schrieb:
Warum empfiehlst Du es nicht? Beides hat Vor- und Nachteile. Der Vorteil von einer Suche mit FULLTEXT/MATCH/AGAINST ist dass es etwas schneller ist (was aber bei kleinen Seiten nicht so sehr von Bedeutung ist) und die Relevanz direkt berechnet werden kann.
Der Vorteil von LIKE ist dass auch Teilworte gefunden werden. Per MATCH/AGAINST wird z.B. nicht "wort" innerhalb von "antwort" gefunden.
Beides hat natürlich seine Berechtigung.

Das ist nicht richtig. Auch bei FULLTEXT gibt es die Möglichkeit
in BOOLEAN MODE zu suchen, was auch Teilwörter einschliesst.
(Siehe MySQL.com -> FULLTEXT / BOOLEAN)
Ausserdem ist die Relevanz für genau solch eine Suche doch sehr
wichtig.
Ich habe solche Website Suchen bei nicht CMS Systemen immer mit
FULLTEXT realisiert. Durch indizierte Seiteninhalte über Meta
Tags, Titel der einzelnen Seiten, kombiniert mit einigen Tricks
zur Relevanzberechnung ganrantiere ich dir "bessere" Such-
ergebnisse!

Ist nur ein Tip, nur wenn mans schon macht, sollte man auch die
dafür entwickelten Funktionen einer Datenbank nutzen. Meine
Meinung :)

Gruß, Micha
 
michanismus schrieb:
Das ist nicht richtig. Auch bei FULLTEXT gibt es die Möglichkeit
in BOOLEAN MODE zu suchen, was auch Teilwörter einschliesst.
(Siehe MySQL.com -> FULLTEXT / BOOLEAN)
Danke für den Tip. Das war mir unbekannt.
 
Mal ganz pauschal gefragt:

Ist es wirklich schneller? Habe hier eine Kundendatenbank (in etwa 8.000 Einträge). Wenn man nach nem Kunden sucht, wird bei mir die jeweilige Spalte mit LIKE durchsucht. Funktioniert ganz gut und schnell.
Mein Problem damals war, dass alle Spalten durchsuchbar sein sollen. Mit FULLTEXT müsste man dann ja jede Spalte indizieren, was ja nicht so toll ist.
 
Jakob schrieb:
Mal ganz pauschal gefragt:

Ist es wirklich schneller? Habe hier eine Kundendatenbank (in etwa 8.000 Einträge). Wenn man nach nem Kunden sucht, wird bei mir die jeweilige Spalte mit LIKE durchsucht. Funktioniert ganz gut und schnell.
Mein Problem damals war, dass alle Spalten durchsuchbar sein sollen. Mit FULLTEXT müsste man dann ja jede Spalte indizieren, was ja nicht so toll ist.

Hi,

schneller:
Es ist auf jeden Fall schneller.
Bei deinen Kundendaten standen auch sicher nur ein paar Wörter
in jedem Feld, was natürlich auch die zu durchsuchene Daten-
größe nicht wirklich in die Höhe treibt. Hättest du aber 8000
Datensätze in denen bedeutet mehr Inhalt ist würdest du auch
einen Unterschied "spüren".
Ich dachte da so an 2000 kb bei 8000 Kundendaten vs.
30000 kb bei 8000 indizierten HTML Seiten.

Was an einer Indizierung "nicht toll" sein soll musst du mir
echt mal erklären! :)

Gruß, Micha
 
Ich weiß leider nicht ab welchen Größenordnungen das bei mySQL gilt, generell ist eine Suche mit Index aber erstmal aufwendiger=langsamer, da er ja erst den Index und dann die Datensätze durchsucht (2 Vorgänge) und nicht nur die Datensätze (1 Vorgang).

Leider hab ich keine Ahnung, ob das in meinem Fall mit den 8000 Kundendaten, also z.B. Suche nach der indizierten Nachname-Spalte schon schneller ist.
 
Jakob schrieb:
... generell ist eine Suche mit Index aber erstmal aufwendiger=langsamer, da er ja erst den Index und dann die Datensätze durchsucht (2 Vorgänge) und nicht nur die Datensätze (1 Vorgang)...

Entschuldige, aber wer hat dir das denn bitte so erklärt???

Ein INDEX ist meistens eine Spalte, nach der besonders häufig gesucht wird. Die Einträge in der Spalte werden als HASH Index gespeichert. Damit beschleunigt sich die Suche erheblich. Insbesondere bei Verknüpfungen von Tabellen wird MySQL dadurch erheblich schneller.

Gruß, Micha
 
Ja das stimmt, aber eben nicht uneingeschränkt. Indizes bringen nur was, wenn es viele unterschiedliche Werte in der Spalte gibt und oft nur kleine Teile der Spalte ausgegeben werden. Oft kommt es vor, dass der Index größer ist als die zu durchsuchende Spalte.

Wenn Du die Geschwindigkeit vergleichst bekommst Du eine steigende Gerade und eine langsamer steigende Kurve. Die Gerade fängt bei 0 an, die Kurve bei z.B. 10 (Index-File muss angeguckt werden). Habe jetzt gelesen, dass über den Daumen gepeilt bei 2000 Einträgen die Gerade die Kurve überholt.

Kommt natürlich noch drauf an, welcher Art Index es ist, neben Hash gibt's ja noch andere (B-Tree usw.) und ob die Suche auf die Indizes optimiert ist.
 
Zurück
Oben Unten