Gå til innhold

Intern søkemotor med kategoristyrt database


Anbefalte innlegg

Heisann!

 

Har et prosjekt gående for tiden, hvor jeg ønsker, som overskriften nevner, å lage en slags intern søkemotor, med en pågående MySQL database. 

Hvordan dette i praksis skal skje, kan forklares ved bruk av eksempler!

 

Bruker 1 går inn på siden, logger inn og legger inn en ny kategori. Kategorien kan være et produkt eller noe annet generelt. Denne kategorien må godkjennes av administratorer før den vises offentlig. Samtidig, kan Bruker 1 skrive en tekst om kategorien som bruker 1 lagde. Teksten må bli moderert før den vises frem.

 

Bruker 2 logger seg inn, søker via Søkemotoren og finner kategorien som bruker 1 har laget. Brukeren går så inn på siden, og skriver en hilsen i kategorien. Denne teksten blir også moderert.

 

Bruker 3 registrerer seg, logger inn og søker via søkemotoren. Brukeren finner ikke sin kategori, og velger heller å lage den selv. Denne blir da sendt til moderering, men brukeren skriver sin kommentar til kategorien, som også blir sendt til moderering. 

Med andre ord, skal alle innlegg/kommentarer/hilsner som skrives under 1 kategori, samles under den ene kategorien, slik at man unngår flere dobbelt-kategorier. Kategoriene skal igjen kunne søkes på, via søkemotoren.

 

Med andre ord, skal hvem som helst ha muligheten til å skape en kategori, og hver kategori, må inn til moderering før den publiseres, det samme gjelder hver kommentar/hilsen. 

 

Skjønner at dette kommer til å være en del arbeid, men hvilke kodespråk tenker folk at jeg trenger for å kunne muliggjøre dette? Finnes det eventuelt andre ferdiglagde scripts/CMS´, som jeg kan benytte meg av, som gjør den samme jobben? 

Endret av LexCore
Lenke til kommentar
Videoannonse
Annonse

Så hver kategori er som en tråd på forumet? Hvorfor kaller du det da kategori og ikke tråd? Og både opprettelse av tråd og innlegg skal godkjennes av "administrator". (Normalt vil man ha en administrator, som har alle rettigheter, inkludert å opprette nye moderatorer, som er de som tar seg av godkjenningen, men ikke kan opprette nye moderatorer.)

 

Frontend: HTML+CSS+Javascript

Backend: Et hvilket som helst backend-språk, som f.eks. JavaScript eller PHP + SQL.

 

Med mindre dere er en gigantisk bedrift, burde det også holde med SQLite istedenfor MySQL.

Endret av Emancipate
Lenke til kommentar

Datastrukturen "post" er ekstremt enkel, og noe som man ofte ønsker å gjøre endringer på i ettertid. Man bruker da gjerne ikke relasjonsdatabaser, men dokumentdatabaser (nosql) som f eks MongoDB. Frontend som nevnt html/js. Mange benytter en stack som kalles MEAN til dette.

Det er ikke så mye arbeid, og det finnes greie videoer. Jeg liker f eks en som heter Traversy som har haugevis med MEAN/REST-totorials

Tegn et flytskjema/user flow på et A4 ark først, så er det enklere å se hvor du skal begynne.

Lenke til kommentar

Nei, for all del aldri bruk MongoDB eller dokumentdatabaser. SQL er så overlegent på alle områder uansett korleis ein vrir og vender på det.

 

Eg foreslår at trådstarter bruker Ruby on Rails eller Grails for å løyse problemet. Det er ganske trivielt å få det gjort fort og bra i dei rammeverka. Finnes mange gode videoer på youtube på korleis du oppretter ein blogg, og der i fra er det enkelt å ta det videre til det du ønsker å løyse.

Lenke til kommentar

 

Nei, for all del aldri bruk MongoDB eller dokumentdatabaser. SQL er så overlegent på alle områder uansett korleis ein vrir og vender på det.

Støttes.

 

Dette var ungdommelig bastant. Usikker på om dere tøyser med hva dere mener, eller om dere mener dette tøyset  :rofl:  

 

Ellers synes jeg bruker beskriver noe nærmere en wiki eller blog, enn et strukturert forum. I så fall tar det jo nesten like kort tid å installere f eks MediaWiki som å skrive sine egen løsning. Ikke akkurat siste mote, men vil sikkert funke i en knipe.

Lenke til kommentar

Så hver kategori er som en tråd på forumet? Hvorfor kaller du det da kategori og ikke tråd? Og både opprettelse av tråd og innlegg skal godkjennes av "administrator". (Normalt vil man ha en administrator, som har alle rettigheter, inkludert å opprette nye moderatorer, som er de som tar seg av godkjenningen, men ikke kan opprette nye moderatorer.)

 

Frontend: HTML+CSS+Javascript

Backend: Et hvilket som helst backend-språk, som f.eks. JavaScript eller PHP + SQL.

 

Med mindre dere er en gigantisk bedrift, burde det også holde med SQLite istedenfor MySQL.

 

 

 

Grunnen til at jeg ikke kaller det en tråd, er nettopp fordi det ikke er et forum, som også RulleRimfrost beskriver. 

 

Det skal ikke forestille noen form for forum, men mer en søkemotor med innlagt database, som inkluderer og sorterer "Innlegg". Innleggene skrives i kategorier som enten er skapte fra før, eller skapes selv av brukeren der og da, om kategorien ikke eksisterer allerede. 

 

Layout-messig, forestiller jeg meg en ganske enkel nettside, hvor man har søkemotorsfeltet plassert midt på siden, med litt tekst over som hjelper brukeren til å kunne gjøre det nettsiden først og fremst er basert på og ment til.

 

Med andre ord, dette er overhodet ikke ment som et forum eller noe annet lignende. 

Endret av InfectedExo
Lenke til kommentar

Det skal ikke forestille noen form for forum

Hva det "forestiller" er helt urelatert fra hva det er. Du fortsetter å beskrive noe som jeg tror at enkelt kan settes opp med et custom phpBB theme og riktige innstillinger. Bytt ut forsiden med et søkefelt som kun søker i titler.

 

 

 

som inkluderer og sorterer "Innlegg"

Du har ikke nevnt sortere før nå, hvordan skal innleggene sorteres?

Endret av Emancipate
Lenke til kommentar

 

en søkemotor med innlagt database

 

Putt det rett i ElasticSearch og skriv en frontend på toppen, da.

 

Når det er sagt tror jeg også at du muligens får en kortere og mer behagelig vei til målet med en SQL-database i bånn og et enkelt rammeverk. Ruby on Rails eller Python+Django kanskje.

 

Databaser som f.eks PostgreSQL støtter fint å blande inn og spørre på ustrukturert innhold dersom du trenger det. Den funksjonaliteten støttes også ut av boksen i Rails.

Lenke til kommentar

 

Det skal ikke forestille noen form for forum

Hva det "forestiller" er helt urelatert fra hva det er. Du fortsetter å beskrive noe som jeg tror at enkelt kan settes opp med et custom phpBB theme og riktige innstillinger. Bytt ut forsiden med et søkefelt som kun søker i titler.

 

 

 

som inkluderer og sorterer "Innlegg"

Du har ikke nevnt sortere før nå, hvordan skal innleggene sorteres?

 

 

 

Hvordan et forum oppfører seg, vil nok ikke kunne samsvare med de forventningene jeg har, og hvordan ting blir lagt inn. Dette skal jo hovedsakelig, slik jeg tenker det, bli lagt direkte i en database, og ikke via et forumsystem. Systemet for hvordan et forum virker, er i stor grad annerledes fra hvordan jeg tenker at dette skal funke på en rask og effektiv måte.

 

Jeg har nok heller ikke direkte nevnt ordet sortere, men det er jo nettopp det jeg har ment, når jeg sier at disse skal inn i kategorier som enten er selvlagd av brukere, eller kategorier som brukere lager der og da, i tilfeller hvor kategorien ikke eksisterer.

 

 

Kan du ikke gi eksempel på innhold? Hva vil bruker 1, bruker 2 og bruker 3 faktisk bruke dette til? :)

 

Hehe, burde kanskje ha gjort nettopp det. Ønsker å lage en slags samleside for feedbacks basically, hvor "kategori" forestiller et produkt. Brukeren kan skrive en "mini-anmeldelse" om et produkt, og finnes ikke produktet allerede, lager man en egen produktside/kategori. Finnes produktsiden/kategori, vil den oppføre seg som en gruppe eller kategori, som tilgjengeliggjør flere anmeldelser.

 

 

 

 

en søkemotor med innlagt database

 

Putt det rett i ElasticSearch og skriv en frontend på toppen, da.

 

Når det er sagt tror jeg også at du muligens får en kortere og mer behagelig vei til målet med en SQL-database i bånn og et enkelt rammeverk. Ruby on Rails eller Python+Django kanskje.

 

Databaser som f.eks PostgreSQL støtter fint å blande inn og spørre på ustrukturert innhold dersom du trenger det. Den funksjonaliteten støttes også ut av boksen i Rails.

Takk for tipset! ElasticSearch må jeg riktignok undersøke litt. Høres faktisk enklere ut, som du nevner, å heller bruke en database som utgangspunkt.

Endret av InfectedExo
Lenke til kommentar

 

Blir ikke denne tittelen villedende når Intel Optane er mellom 10-1000x raskere?

Er du morsom? 10 ganger så rask? 1000 ganger så rask? Har du røyket?

 

 

Eg vil påstå at Elasticsearch er for vanskeleg. Det er eit sinnsjukt bra produkt, men det er svært mykje å lese seg opp på.

 

PostgreSQL har også innebygd fulltekst-søk, med innebygd stemming for forskjellige språk. Den er ofte god nok.

 

Kjapt eksempel:

CREATE TABLE my_table (
  id serial,
  my_text_vector tsvector, 
  my_text1 text, 
  my_text2 text
);
INSERT INTO my_table (my_text1, my_text2) VALUES (
  'olav liker å trykke på tastaturet',
  'det liker jeg ikke'
);
 
INSERT INTO my_table (my_text1, my_text2) VALUES (
  'Vidar liker å bade i et svømmebasseng',
  'Vidar bruker også badering'
);
UPDATE my_table
SET my_text_vector = to_tsvector(
  concat_ws(' ',
    my_text1::text,
    my_text2::text
  )
);
SELECT * FROM my_table
WHERE my_text_vector @@ to_tsquery('olav:* & tryk:* & jeg:*');

Merk at :* betyr wildcard (eller enklare forklart, ordet starter med følgende bokstaver)

& betyr at du forventer et treff på dette ordet også.

 

)

);

Lenke til kommentar

 

 

Eg vil påstå at Elasticsearch er for vanskeleg. Det er eit sinnsjukt bra produkt, men det er svært mykje å lese seg opp på.

 

PostgreSQL har også innebygd fulltekst-søk, med innebygd stemming for forskjellige språk. Den er ofte god nok.

)

);

 

 

Har du testet disse opp mot hverandre mtp ytelse, har selv brukt solr - som jo bygger på det samme som elasticsearch - i en årrekke, og også brukt postgresql, men aldri fulltekstsøket i postgres. Hadde vært kjekt å slippe solr i tillegg til postgresql.

 

Til TS:

Tror det er viktig at du tenker gjennom denne søkemotoren, hvilke krav som stilles, både mtp datamengde, samtidige søk, responstid, .... Dersom du ikke har noe erfaring med koding fra før av, så kan prosjektet ditt ta ganske så mye tid.

Lenke til kommentar

Ytelsen er tilsvarende, du kan opprette enten gist eller gin index for betre søkeytelse. Fordelen er jo at du kan framleis bruke SQL for datauttrekk istadenfor å måtte lære deg ny syntax for å kjøre dataspørringer i Lucene/Solr/Elasticsearch.

 

For rein fulltekst søk så skalerer jo Solr og Elasticsearch mykje betre på store datamengder da dei sharder data og sprer dei utover fleire noder. Og da snakker eg om datamengder på fleire 100+++ TB. Har du mindre enn det, så er truleg PostgreSQL godt nok.

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...