Waarom doen de meeste search boxes op web pagina's "OR"

[marcel2104]

Hier zitten vast wel wat Tweakers die aan web development doen. Ik erger mij regelmatig aan search opties op websites. Standaard lijken de meeste search engines van websites een OR in plaats van een AND te doen.

imho beperkt dit de kans om iets geschikts te vinden behoorlijk.

Als het een "AND" zou zijn, kan je altijd meerdere zoek acties doen op individuele keywords. Bij een OR is er geen enkele mogelijkheid om het zoek gebied te verkleinen.

Recent voorbeeld waar ik net tegenaan liep. Website KPN zoeken naar info m.b.t. het email adres dat voor de faktuur gebruikt wordt.

Zoeken op email levert een hoop hits op m.b.t. email instellingen.
Zoeken op faktuur levert een hoop hits op m.b.t. financiele aspecten.
Zoeken op: email faktuur levert ook tientallen pagina's met hits op waar je dus niets aan hebt.

Enig idee dit het standaard gedrag is op veel sites ? Enige logica, of bedacht door mensen die nooit iets zoeken ?

KPN is een voorbeeld, maar zo zijn er vele websites. Of is er misschien een standaard optie om een AND toe doen die ik niet weet ?

[Voutloos]

Voor zowel OR als AND is wel iets te zeggen, dus het is wellicht arbitrair. Mogelijk is het nadeel van OR initieel minder merkbaar als hoeveelheid content nog moet groeien, of als je het CMS bouwt zonder de productiedata.

Voor het gegeven voorbeeld: Zoek gewoon ‘ email factuur site:kpn.com’ in je favo search engine.

[Gomez12]

Veelal omdat (mits je geen gespecialiseerde zoek-machine gebruikt) OR ontelbaar keer makkelijker te integreren is in een gemiddeld DBMS met een half doorgevoerd normaliseringsschema(/ waar er enkel genormaliseerd is en nergens gedenormaliseerd)

Stel dat elke kpn pagina zou bestaan uit de volgende elementen in een database :
- Subgroep
- Artikelnaam
- Artikelbegin
- Artikelvervolgstuk
- Artikelafsluiting

Dan kan je met een or gewoon zeggen (met 1 waarde) :
select * where Subgroep like 'zoekwaarde' or artikelnaam like 'zoekwaarde' or artikelbegin like 'zoekwaarde' ...
dit is supersimpel uitbreidbaar naar meerdere zoekwoorden, dan krijg je gewoon subgroep like 'zoekwaarde1' or subgroep like 'zoekwaarde2' or artikelnaam like 'zoekwaarde1' or artikelnaam like 'zoekwaarde2'
en hij spuugt gewoon alle documenten retour die 1 of meerdere zoekwoorden bevatten.
Je kan dit ook heel simpel optimaliseren door een lijst van unieke woorden te maken en die terug te koppelen naar de basistabellen.

Echter voor een AND, dan heb je opeens een extra virtuele entiteit nodig binnen je genormaliseerde datamodel wat zegt wat een artikel is, zodat je al die velden bij elkaar kan houden en daar doorheen kan zoeken.

Als er ook fatsoenlijk gedenormaliseerd is, dan is het helemaal niet zo'n groot probleem meer, want dan heb je gewoon ergens een gedenormaliseerd veld staan met searchdata die gewoon alle data uit subvelden bevat.
Alleen praktisch zie ik veel slecht gedenormaliseerde dbms'en omdat men enkel maar uitgaat van normalisatie en dan is het gewoon een ramp.

Of beter gezegd, probeer zelf eens een OR uit te schrijven voor het doorzoeken van 5 velden met 5 zoekwoorden.
En schrijf nu eens met dezelfde data een AND uit.
Het is wel te doen, maar het is simpelweg meer werk. En dan moet je het normaal zien dat er al snel 50 of nog meer velden doorzocht moeten worden.

[Verwijderd]

Of beter gezegd, probeer zelf eens een OR uit te schrijven voor het doorzoeken van 5 velden met 5 zoekwoorden.

code:

where field1 LIKE "%query%" OR field2 LIKE "%query%" OR field3 LIKE "%query%" OR field4 LIKE "%query%" OR field5 LIKE "%query%"

En schrijf nu eens met dezelfde data een AND uit.

code:

where field1 LIKE "%query%" AND field2 LIKE "%query%" AND field3 LIKE "%query%" AND field4 LIKE "%query%" AND field5 LIKE "%query%"

[ACM]

Verwijderd schreef op donderdag 7 januari 2021 @ 06:29:

code:

where field1 LIKE "%query%" OR field2 LIKE "%query%" OR field3 LIKE "%query%" OR field4 LIKE "%query%" OR field5 LIKE "%query%"

code:

where field1 LIKE "%query%" AND field2 LIKE "%query%" AND field3 LIKE "%query%" AND field4 LIKE "%query%" AND field5 LIKE "%query%"

Je beide queries gaan uit van 1 term in 5 velden, niet van meerdere termen. Een like in SQL kan sowieso alleen specifieke termen of termen in de gegeven volgorde doen. Dus die query zal al opgesplitst moeten worden in losse termen.

Maar je AND zal heeel weinig resultaten geven, want die verplicht dat de term voor ieder document in alle 5 de velden voorkomt...

Als je een OR wilt doen met twee termen is het zoiets:

code:

where field1 LIKE '%term1%' OR field1 LIKE '%term2%' OR field2 LIKE '%term1%' OR field2 LIKE '%term2%'  ...

Een AND-variant is ook niet zo moeilijk, dat kan zo:

code:

where (field1 LIKE '%term1%' OR field2 LIKE '%term1%' ...) AND (field1 LIKE '%term2%' OR field2 LIKE '%term2%'  ...)

Sterker nog, als je die eerste herschrijft hiernaartoe kan je verder vrijwel dezelfde logica gebruiken:

code:

where (field1 LIKE '%term1%' OR field2 LIKE '%term1%' ...) OR (field1 LIKE '%term2%' OR field2 LIKE '%term2%'  ...)

Al met al zal het verder in SQL nooit echt een goed resultaat geven als je zaken als relevantie wilt meenemen. Dan zal een like-search niet volstaan.

Gebruik je echter een standaard zoekmachine(bibliotheek) dan is weer de kans groot dat het zowel AND als OR ondersteund.

Al met al zou ik ook niet weten waarom websites vaak OR-search bieden. Soms komen er dan nog door relevantie-sortering de resultaten waar alle termen in staan meer naar boven en heel soms ondersteunen ze het keyword AND of +-jes, maar het blijft lastig zoeken in zulke sites.

Overigens zijn zoekmachines ook daadwerkelijk moeilijk om te maken en moet je met van alles rekening houden. @marcel2104 schrijft bijvoorbeeld faktuur ipv factuur. Dan moet faktuur maar net bekend zijn gemaakt als taalfout-synoniem van factuur (wat blijkbaar wel is gedaan bij kpn).

[DJMaze]

marcel2104 schreef op woensdag 6 januari 2021 @ 21:00:
Hier zitten vast wel wat Tweakers die aan web development doen. Ik erger mij regelmatig aan search opties op websites. Standaard lijken de meeste search engines van websites een OR in plaats van een AND te doen.

Heb je wel eens een + of - geprobeerd om te zoeken, net als in google?

[Hydra]

marcel2104 schreef op woensdag 6 januari 2021 @ 21:00:
Hier zitten vast wel wat Tweakers die aan web development doen. Ik erger mij regelmatig aan search opties op websites. Standaard lijken de meeste search engines van websites een OR in plaats van een AND te doen.

Ik heb 10 jaar bij een search engine vendor gewerkt.

Text search is moeilijk en het is meetal een beetje een ondergeschoven kindje. Als je het breed doet (bijv OR) krijg je veel resultaten, maar vaak niet wat je wl. Als je het smal doet (AND) krijg je veel minder resultaten, maar meer wat je wil.

Het probleem is alleen dat "de business" een search die nul resultaten geeft als een 'bug' ziet, ook als de data er echt niet is. Dus waar je meestal op uit wil komen is een 'gewogen' search a la google, dat hoe meer kenmerken matchen hoe hoger het komt. Maar dan wil je ook weer stop-woorden uitfilteren.

Dit allemaal doen met 'gewoon' een database is lastig, dus je moet er al iets als elastic search (of de DB waar ik toen voor werkte) naast gaan zetten. En dat is veel werk. En als je als developer op de vraag "hoe lang gaat het fixen van de search bug duren" antwoordt met "2 maanden" dan is het al snel een "laatmaar".

Search echt goed doen kost gewoon flink wat geld.

[Bender]

Als je OR doet, kun je resultaten ook gaan sorteren op welke woorden er beide in voorkomen.
Hierdoor komen er meerdere relevante resultaten bovenaan.

[RagingPenguin]

ACM schreef op donderdag 7 januari 2021 @ 07:08:
[...]
Al met al zou ik ook niet weten waarom websites vaak OR-search bieden. Soms komen er dan nog door relevantie-sortering de resultaten waar alle termen in staan meer naar boven en heel soms ondersteunen ze het keyword AND of +-jes, maar het blijft lastig zoeken in zulke sites.

Overigens zijn zoekmachines ook daadwerkelijk moeilijk om te maken en moet je met van alles rekening houden. @marcel2104 schrijft bijvoorbeeld faktuur ipv factuur. Dan moet faktuur maar net bekend zijn gemaakt als taalfout-synoniem van factuur (wat blijkbaar wel is gedaan bij kpn).

Hydra schreef op donderdag 7 januari 2021 @ 09:14:
[...]

Het probleem is alleen dat "de business" een search die nul resultaten geeft als een 'bug' ziet, ook als de data er echt niet is. Dus waar je meestal op uit wil komen is een 'gewogen' search a la google, dat hoe meer kenmerken matchen hoe hoger het komt. Maar dan wil je ook weer stop-woorden uitfilteren.

Dit allemaal doen met 'gewoon' een database is lastig, dus je moet er al iets als elastic search (of de DB waar ik toen voor werkte) naast gaan zetten. En dat is veel werk. En als je als developer op de vraag "hoe lang gaat het fixen van de search bug duren" antwoordt met "2 maanden" dan is het al snel een "laatmaar".

Search echt goed doen kost gewoon flink wat geld.

Veel databases kunnen dat ook full-text search met indexing, relevantie en alle dingen die je zou verwachten (Postgres, Sql Server en Mysql bijvoorbeeld). Maar verder eens, goede search is moeilijk en kost een hoop tijd om het echt goed te doen. En in-database search scheelt het opzetten van een extra search database met een indexing sync, maar de hoeveelheid (web-)developers die meer SQL kunnen dan SELECT * FROM USER is al bedroevend laag.