Gå til innhold

[Løst]Effektiv implementasjon av leksikon


Anbefalte innlegg

Heisann, jeg sitter og lager et slags leksikon for mat til eget bruk som et lite hobbyprosjekt innen webutvikling. Planen er et veldig enkelt grensesnitt - det skal være en tekstboks hvor jeg skriver inn noe jeg ønsker å vite, og etterhvert som jeg skriver vil applikasjonen via AJAX hente frem artikler som er relevante til det jeg har skrevet inn.

 

PHP'en og Javascriptingen har jeg grei kontroll på, men jeg er veldig fersk med SQL, så jeg har ikke så mange gode ideer for hvordan jeg kan implementere dette effektivt. Det jeg har skriblet ned er at etter hvert som søketeksten blir skrevet inn, deles det opp i nøkkelord. For eksempel, om jeg skriver "Middag med kjøttdeig som er rask å lage", kan den kjenne igjen "middag", "kjøttdeig" og "rask" fra en liste med nøkkelord, og deretter søke etter artikler som inneholder ett eller flere av disse. Deretter kan den sortere resultatene etter relevans ut ifra hvor mange nøkkelord som ble matchet, osv. I tabellen med artikler tenkte jeg da at hver oppføring skal ha et felt som inneholder alle nøkkelordene som er relevante for artikkelen (disse blir altså definert manuelt).

 

Hvordan kan jeg løse dette på en effektiv måte? Jeg regner jo med at den åpenbare, enkle metoden med å bare søke igjennom alle artiklene for å se om nøkkelordet finnes i listen til noen av dem, er like lite effektiv som den er elegant. Burde jeg ha en egen tabell med alle nøkkelordene i ved siden av? Burde alle disse nøkkelordene igjen "speile" seg med artiklene så hvert nøkkelord også inneholder indeksene til alle artiklene som omhandler det?

 

Jeg lurer rett og slett på hvordan jeg burde designe databasen til dette formålet. Og hvordan bør jeg utforme spørringene mot databasen? Jeg bruker MySQL5 med MySQLi extension om det skulle være relevant. Noen som har noen tips til dette?

Endret av Wedvich
Lenke til kommentar
Videoannonse
Annonse

Kjem litt ann på kompetansenivået du legg opp til men SQL-søk er ein veldig dårlig løysning på å finne fram tekst basert på eit søkeord eller fleire.

Ideelt sett bør du ha ein eller anna form for søkemotor som gjer søket så kan heller resten av applikasjonen ta imot ein id og slå opp i databasen etter artiklene.

 

Solr er ein søkemotor som er gratis og vil fungere veldig godt til den bruken du skisserer opp her. Sjølve "framhentinga" ville eg nok prøvd brukt Solr`s autocomplete til. Den skal kunne gi deg eit fornuftig resultatsett før artiklene blir funne fram og vist.

 

sIDDIs er nok enig i at solr vil løyse problemet også.

Lenke til kommentar
...

Solr er ein søkemotor som er gratis og vil fungere veldig godt til den bruken du skisserer opp her. Sjølve "framhentinga" ville eg nok prøvd brukt Solr`s autocomplete til. Den skal kunne gi deg eit fornuftig resultatsett før artiklene blir funne fram og vist.

 

sIDDIs er nok enig i at solr vil løyse problemet også.

Godt forslag. Solr er forøvrig en java-applikasjon og krever f.eks. Tomcat.

Lenke til kommentar

Hm, tviler på at fulltekstsøk er noe aktuelt, mulig jeg forklarte tankegangen min litt dårlig. Jeg tenker ikke at hver gang jeg søker, skal den gå igjennom hver artikkelen for å lete etter nøkkelordene i teksten. Jeg forestiller meg en egen tabell for nøkkelord som blir oppdatert manuelt etterhvert som jeg legger inn artikler. Noe a la formen

id INT UNSIGNED NOT NULL AUTO_INCREMENT PRIMARY KEY,
tag VARCHAR(32) NOT NULL DEFAULT '' UNIQUE KEY,
ref BLOB

tag er selve nøkkelordet, f.eks. "kylling" eller "oregano". Så om jeg foreksempel søker på "wok med kylling", og "wok" og "kylling" er registrerte nøkkelord, finner jeg frem til oppføringen på det nøkkelordet i databasen. Så henter den ut den "ref" feltet fra den oppføringen (veldig usikker på om BLOB er best å bruke her, tips?). Innholdet der er, siden MySQL så vidt jeg vet ikke støtter arrays, et PHP-array som er implodert til en tekststreng. Dette arrayet inneholder ID'ene til alle artiklene med den taggen (altså er det gjerne på formen "3;7;28;65". Dette må da eksploderes til et array igjen, og så hentes alle artiklene (i hvertfall tittelen og et kort sammendrag av dem) med disse id'ene ut fra databasen. Dette gjøres for hvert nøkkelord. Så slår jeg sammen resultatene av spørringene i PHP, og sorterer dem etter relevans (som jeg tenkte å regne ut ifra hvor mange av nøkkelordene som matcher; altså, en artikkel som matcher "wok" og "kylling" er mer relevant enn en som bare matcher "wok" eller "kylling"). Og så dyttes det altså frem på skjermen min.

 

Er dette en dårlig løsning? Jeg er ganske innstilt på å bruke MySQL selv om det gjerne ikke er optimalt - jeg kjører Apache med PHP og har en MySQL-server i tillegg, og jeg håper at jeg kan slippe å måtte sette meg inn enda flere ting (som Tomcat/Solr). Så gitt de forutsetningene for servermiljøet jeg skal kjøre den på - Apache/PHP/MySQL - er den løsningen jeg har tenkt ut brukbar? Eller finnes det en smartere måte å designe det på?

 

EDIT: Klippe og glemme å lime, tsk tsk... anyway:

Kaster denne forklaringen tingene i nytt lys? Eller er Solr såpass overlegent til dette formålet at jeg bare må krype til korset og begynne å lese og lære for at dette i det hele tatt skal bli mulig?

Endret av Wedvich
Lenke til kommentar

Det du har brukt for er ein søkemotor, alternativt skrive ein helvetes algoritme (og effektiv) for å kunne handtere 50-100K artikler.

 

SQL mot tekstsøk er ikkje ein effektiv vei.

I tillegg så blir det å definere keywords som effektive søkeord eit sant mareritt om dette skal gjerast mot kvar artikkel.

 

Søkemotorer som Solr gjer dette meir eller mindre automatisk (det er komplekse algoritmer i bunnen)

 

Enklaste måte å få opp Solr på er å kjøre jetty, faktisk så er standardpakken ein laster ned klar til å kjøre med jetty, README-fila beskriver korleis du gjer det.

 

For din del kan du sjå på solr som ein webtjeneste som svarer på http-foresprusler.

Det einaste som du må gjere er å omforme dataene du har i databasen over til solr-dokument for indeksering, og så ha ein klient som spør. Heldigvis finnes det både ajax og php-klienter du kan bruke / kopier slik at det bir enklast mulig.

 

Solr-skjemaet må også defineres men det er ikkje så vanskeleg, opprett felt for kvart "element" Title, body , id ......

Til dette er det mange nettresusser og nok ein del her på forumet som kan svare på.

Endret av Jankee
Lenke til kommentar
Er dette en dårlig løsning? Jeg er ganske innstilt på å bruke MySQL selv om det gjerne ikke er optimalt - jeg kjører Apache med PHP og har en MySQL-server i tillegg, og jeg håper at jeg kan slippe å måtte sette meg inn enda flere ting (som Tomcat/Solr). Så gitt de forutsetningene for servermiljøet jeg skal kjøre den på - Apache/PHP/MySQL - er den løsningen jeg har tenkt ut brukbar? Eller finnes det en smartere måte å designe det på?

 

EDIT: Klippe og glemme å lime, tsk tsk... anyway:

Kaster denne forklaringen tingene i nytt lys? Eller er Solr såpass overlegent til dette formålet at jeg bare må krype til korset og begynne å lese og lære for at dette i det hele tatt skal bli mulig?

 

Solr er enkelt å komme igang med. Tror du kan avgjøre selv om den er noe for deg på ca 20-30 minutter.

 

Spørsmålet er vel egentlig hva du vil. Vil du ha funksjonalitet raskest mulig? I såfall er det nesten aldri lønnsomt å lage noe selv fra scratch. Hvis du derimot vil lære noe så blir spørsmålet hva? Lage en søkemotor, eller bruke en søkemotor? Du kan helt sikkert løse behovet ditt ved å bruke MySQL og PHP langs de linjene du har skissert, men også da vil jeg sterkt anbefale deg å se på hvordan andre har løst ting før deg.

Lenke til kommentar

Opprett en konto eller logg inn for å kommentere

Du må være et medlem for å kunne skrive en kommentar

Opprett konto

Det er enkelt å melde seg inn for å starte en ny konto!

Start en konto

Logg inn

Har du allerede en konto? Logg inn her.

Logg inn nå
×
×
  • Opprett ny...