[MYSQL] MATCH() AGAINST() probleempje met koppeltekens

[Verwijderd]

Ik heb een query

SELECT * FROM foto WHERE MATCH (name, keywords, description) AGAINST ('$_GET[query]')

Bij een record waar de foto.name de value "11-11-11 Aktie 1980" heeft kan ik met het opzoeken met de query "11-11-11" of "11 11 11" dat resultaat niet weergeven omdat MySQL (versie 3.23 btw) die koppeltekens uit de query haalt.

Wat zijn mijn mogelijkheden buiten niet die MATCH AGAINST te gebruiken, want die werkt buiten dit kleine probleempje wel zeer snel, eenvoudig en goed?

[drm]

matcht 111111 wel met 11-11-11 ? Dan zou je bijvoorbeeld zelf de koppeltekens eruit kunnen halen als je een dergelijke string tegen komt... Anders wordt 't de REGEXP, LIKE of zelf-index-zut toer, ben ik bang.

[Verwijderd]

drm schreef op 02 januari 2003 @ 20:58:
matcht 111111 wel met 11-11-11 ? .

11-11-11 noch 11 11 11 noch 111111 matchen

[ACM]

Het probleem zou wel eens nog iets groter kunnen zijn, namelijk dat mysql de 11 11 en 11 niet eens opslaat in de fulltext-index (twee tekens of korter worden standaard niet opgeslagen).
Dat kon je, meen ik, ergens instellen, zoja dan zou je dat es moeten veranderen. Anders kan je dus op geen mogelijkheid die data terugvinden, want die staat gewoon niet in de ft-i.

[Verwijderd]

Hmm ik dacht gelezen te hebben dat de minimumlengte 4 tekens was... om dit te verminderen moet je dit in de sourcecode van MySQL aanpassen, maar daar heb ik geen zin in... Mede omdat de applicatie op servers van de overheid moet draaien waar ik verzekers geen custom buildjes op ga mogen doen... Ach ja dan laat ik het maar... Pech voor hen...

[drm]

Dan zou ik er toch voor kiezen om zelf te indexeren. Wellicht dat je dan eerst een "onderzoekje" kan doen waarop veel gesearched wordt, zodat je je index daar een beetje zelf op aan kan passen. Oftewel, zoektermen die bezoekers gebruiken opslaan.

[Verwijderd]

Dit wordt al lastig omdat het hier om een foto-archief gaat welke dagelijks aangevuld wordt met tientallen foto's met naam, beschrijving en kernwoorden waar m'n op moet kunnen zoeken. Ik kan natuurlijk een hele vette LIKE query schrijven ook maar dit zal wel serieus ten koste van de performance gaan... Ik denk dat ik voorlopig de kat uit de boom ga kijken en het zo ga houden tot er de vraag naar komt en er wat meer eurotjes op de tafel gegooid worden. Toch bedankt!

Even offtopic: Hoe zit de GoT search in mekaar want die is toch vrij snel heb ik de indruk

[CyberSnooP]

Buiten het feit dat het vervelend is dat het op deze manier niet geïndexeerd wordt toch een vraagje:
Is het een datum? En waarom staat die datum niet in een apart veld in de database?

Verwijderd schreef op 03 januari 2003 @ 20:04:
Even offtopic: Hoe zit de GoT search in mekaar want die is toch vrij snel heb ik de indruk

* CyberSnooP *

[Verwijderd]

CyberSnooP schreef op 03 januari 2003 @ 20:55:
Buiten het feit dat het vervelend is dat het op deze manier niet geïndexeerd wordt toch een vraagje:
Is het een datum? En waarom staat die datum niet in een apart veld in de database?

Neen het is geen datum, het is een onderdeel van de naam van een foto... een foto kan uiteraard ook een datum hebben maar die zit in een datum-veld ;-) Dus daar kan wel perfect op gezocht worden welliswaar met een andere query