WN

WN (https://www.wn.se/forum/index.php)
-   Serversidans teknologier (https://www.wn.se/forum/forumdisplay.php?f=4)
-   -   Avancerad sökfråga (MySQL) (https://www.wn.se/forum/showthread.php?t=1058627)

yakuzaemme 2013-07-25 23:16

Avancerad sökfråga (MySQL)
 
Jag har en rätt klurig fråga.

Säg att jag har en databas med många företag i Sverige, med kolumnerna namn och stad.

Håller på att bygga sökfunktionen men får det inte riktigt som jag vill.

Jag vill exempelvis söka på "Apotek Västerås", frågan ser ut såhär:

Kod:

SELECT *, MATCH(namn, stad) AGAINST('apotek sala') as score FROM foretag WHERE MATCH (namn,stad) AGAINST('apotek sala') ORDER BY score DESC
Det finns totalt 1 apotek i Sala, vilket är det enda jag vill visa. Det frågan gör nu är att visa det rätta apoteket högst upp, följt med andra matchningar på antingen "apotek" eller "Sala"

Hur gör jag för att göra den smartare och ge mig mer exakta matchningar? Har nämligen så den visar antal träffar, och söker man på, i detta exempel, apotek sala och den visar hundratals så blir man som användare fundersam.

Använder FULLTEXT + MySQL

Mvh,

Erik Stenman 2013-07-25 23:25

Having score > 5 t.ex.
Sedan är det väl inte nödvändigt att göra en match against för stad-kolumnen. Du kan ju köra where stad='Sala'

yakuzaemme 2013-07-25 23:34

Citat:

Ursprungligen postat av Erik Stenman (Inlägg 20474549)
Having score > 5 t.ex.
Sedan är det väl inte nödvändigt att göra en match against för stad-kolumnen. Du kan ju köra where stad='Sala'

Testade innan med having score, söker jag på "apotek sal" så visar den 0 resultat, "apotek sala" så visar den 1, alltså för strikt. Sänker jag x (score > x) så visar den återigen orelevanta resultat.

Det är ju fritext sökning, du ska alltså kunna söka på "apotek sala", "apotek", "sala" eller som du vill, och givetvis andra städer eller namn.

Tack för svar

b_andersson 2013-07-26 12:33

Strunta i att använda mysql fulltext, det suger. Kolla på Sphinx istället.

Clarence 2013-07-26 12:50

Sphinx/Solr är skalbara, snabbare och mer kapabla. Vill du använda MySQL fulltext search och få resultaten där båda matchar så får du göra en intersect mellan två fulltext sökningar. Och MySQL stödjer inte intersect så du måste göra en INNER JOIN mellan två fulltext search resultat ... vilket leder till en väldigt ineffektiv query ... och sen måste du ändå hämta ut datan med en tredje.

Conny Westh 2013-07-26 13:22

Ett lite jobbigare sätt är att lägga upp en separat tabell med de sökord du vill kunna söka på och ha en länktabell som länkar ihop sökordet med den verkliga förekomsten i din datatabell.

Då kan du låta din sökordstabell vara unikt indexerad och därmed få blixtnsnabba sökningar på sökorden.

Sen får du göra en filtrering med hjälp av förekomsterna i länktabellen. Sökorden måste du då lägga upp när du lägger till nya och uppdaterar poster i din stora datatabell.

Det blir mer jobb att skapa en sån lösning men det kan bli snabbare sökningar om du inte behöver 100% av fritextsökningens funktionalitet.

yakuzaemme 2013-07-26 13:35

Citat:

Ursprungligen postat av ConnyWesth (Inlägg 20474583)
Ett lite jobbigare sätt är att lägga upp en separat tabell med de sökord du vill kunna söka på och ha en länktabell som länkar ihop sökordet med den verkliga förekomsten i din datatabell.

Då kan du låta din sökordstabell vara unikt indexerad och därmed få blixtnsnabba sökningar på sökorden.

Sen får du göra en filtrering med hjälp av förekomsterna i länktabellen. Sökorden måste du då lägga upp när du lägger till nya och uppdaterar poster i din stora datatabell.

Det blir mer jobb att skapa en sån lösning men det kan bli snabbare sökningar om du inte behöver 100% av fritextsökningens funktionalitet.

Tror inte det skulle fungera så bra i praktiken då det ska användas för att visa resultat på olika företag runtom Sverige, ca 9000 inlagda i dagsläget. Du ska alltså kunna söka på "Apotek Göteborg", "McDonalds Fagersta" osv osv, så att ha förbestämda sökfrågor fungerar inte så bra.

Clarence 2013-07-26 14:08

Förutbestämda sökfrågor var något populärt för små projekt för 10+ år sedan för att det saknades bra tillgänglig teknik alternativt kunskap för att effektivt skapa smarta sökfunktioner. Sen kom diverse enklare implementationer i databaserna att bli vanligare, antingen med fulltext eller med en indexeringstabell. Gemensamt är att de inte är vidare flexibla, skalbara eller för den delen - enkla att använda på något annat sätt än väldigt ineffektivt så fort man vill ändra default-beteendet.

Nu finns dock två väldigt kompetenta specialiserade OSS mjukvaror i Sphinx och SOLR. Väljer du att använda MySQL (eller MSSQL, Oracle etc) som sökindex så har du också valt komplexitet, oflexibilitet, ineffektivet, <insert random negative attribute here>.

yakuzaemme 2013-07-26 14:44

Citat:

Ursprungligen postat av Clarence (Inlägg 20474588)
Förutbestämda sökfrågor var något populärt för små projekt för 10+ år sedan för att det saknades bra tillgänglig teknik alternativt kunskap för att effektivt skapa smarta sökfunktioner. Sen kom diverse enklare implementationer i databaserna att bli vanligare, antingen med fulltext eller med en indexeringstabell. Gemensamt är att de inte är vidare flexibla, skalbara eller för den delen - enkla att använda på något annat sätt än väldigt ineffektivt så fort man vill ändra default-beteendet.

Nu finns dock två väldigt kompetenta specialiserade OSS mjukvaror i Sphinx och SOLR. Väljer du att använda MySQL (eller MSSQL, Oracle etc) som sökindex så har du också valt komplexitet, oflexibilitet, ineffektivet, <insert random negative attribute here>.

Låter helt klart intressant och vill kolla in i det, men MySQL är det enda som kan användas i dagsläget, så måste tyvärr köra med det.

Mvh,

Conny Westh 2013-07-26 20:14

Citat:

Ursprungligen postat av Clarence (Inlägg 20474588)
Förutbestämda sökfrågor var något populärt för små projekt för 10+ år sedan för att det saknades bra tillgänglig teknik alternativt kunskap för att effektivt skapa smarta sökfunktioner. Sen kom diverse enklare implementationer i databaserna att bli vanligare, antingen med fulltext eller med en indexeringstabell. Gemensamt är att de inte är vidare flexibla, skalbara eller för den delen - enkla att använda på något annat sätt än väldigt ineffektivt så fort man vill ändra default-beteendet.

Nu finns dock två väldigt kompetenta specialiserade OSS mjukvaror i Sphinx och SOLR. Väljer du att använda MySQL (eller MSSQL, Oracle etc) som sökindex så har du också valt komplexitet, oflexibilitet, ineffektivet, <insert random negative attribute here>.

Jag påstår inte att det är optimalt med fasta sökbegrepp, men av trådens första inlägg tycker jag det verkar vara ett alternativ i just detta fall. Ja det är betydligt mindre flexibelt, jämfört med moderna fulltextsökningar. Men det funkar och det är snabbt.

Man måste givetvis lägga upp alla ord man vill kunna söka på i en separat tabell, men man gör det givetvis genom en SP som tar hand om detta så att den parsar av de texter som ska indexeras och lägger upp de sökord som ska med. är det bara 9000 sökord eller poster så verkar det vara en munsbit som en databas sväljer utan några som helst problem.


Alla tider är GMT +2. Klockan är nu 20:09.

Programvara från: vBulletin® Version 3.8.2
Copyright ©2000 - 2025, Jelsoft Enterprises Ltd.
Svensk översättning av: Anders Pettersson