[ALG] zoek string naar SQL

[zoepercavia]

ik ben bezig voor de zoekmachine op mn site een functie te maken die een searchstring om zet naar SQL, bv.

code:

[b]"koe met poten" kip hond "in boerderij"[/b] naar [b]WHERE var LIKE '%koe met poten' AND var LIKE '%kip%' AND var LIKE '%hond%' AND var LIKE '%in boerderij%'[/b]

ik had al iets met veel ifs en replaces, maar vond het nog al lelijk. Nou vroeg ik me af wat de beste manier is om een bepaald soort string om te zetten in een andere. Is daar iets formeels/theoretisch voor? Hoe los je bijvoorbeeld netjes de substrings op en hoe ga je om met misvormde input? Ik zat zelf te denken aan iets recursiefs, maar misschien zijn er nog andere oplossingen?

[Juup]

Dit is behoorlijk ziek. Kan je dat niet wat netter oplossen met wat select boxen ofzo?

[whoami]

Waarom is het ziek? Het is toch een interessant probleem, en gebruiksvriendelijk is het ook.

[zoepercavia]

Het is toch een interessant probleem

das dus ook een beetje het idee waarom ik het vraag, het gaat niet om de oplossing, die is eral, maar ik vind em lelijk, maar om de weg er naar toe. Ik vroeg me af wat de 'nette' weg is om dit probleem op te lossen. En wat de ideeën daar over zijn...

[_Thanatos_]

Als je MSSQL gebruikt als database, zou ik als ik jou was geen LIKE-clauses gebruiken, omdat die nooit gebruik maken van een index. Je kunt voor het zoeken naar teksten het best een full-text index gebruiken en dan de CONTAINS-clause erop loslaten.

MySQL heeft zoiets ook en Oracle ook vast wel. Access in ieder geval niet

[Glimi]

Jupz FULLTEXT met MATCH is hier het keyword.

Kijk hiervoor onderop bij http://www.mysql.com/doc/en/Fulltext_Search.html , bij de uitleg van boolean mode bij de MATCH, dat is echt om van te voor jou denk ik, in vergelijking met deze query. Immers hier is niet op relevantie te sorteren (hoe vaak komen de woorden voor ) en bij MATCH wel, wat een must is voor zoekmachines!!

Over de input: Je kan 2 soorten input kiezen. Of men gebruikt een natuurlijke taal voor input, waarnaar het programma dit probeert te vertalen, of men eist een bepaalde syntax van de input. Men kiest meestal omdat natuurlijke taal ontzettend moeilijk is, kijk maar bijv naar spraak engines! Deze vorm laat ik dan ook buiten beschouwing.

Als je werkt dmv van Syntax, is het vaak verstandig om de standaard (bijv google) aan te houden. Dus + voor erbij, - voor niet en " " voor dicht bij elkaar, echter dat is uw feestje. Maak echter een duidelijke beschrijving van je syntax. Zou zou jij kunnen bepalen dat geen operatoren achter elkaar mogen komen te staan of dat er in de " " operator geen andere operator mag komen te staan.

Om dan de boel netjes uit elkaar te houden zou je kunnen werken door middel van het beschouwen van het woord + zijn operator (+, - ) als een expressie. Deze expressie bied je dan aan aan een class, die de expressie bekijkt, evalueert en afdoende in een SQLquery (of een tijdelijke array) stopt.

Ook zou je het op de XML manier kunnen aanpakken. De operator beschrijft de functie van het woord. Je zou het dus zo kunnen zien dat

code:

+hondje -fikkie

gelijk is aan

code:

<matchenVanDitWoord>
hondje
</matchenVanDitWoord>
<nietMatchenOpDitWoord>
fikkie
</nietMatchenOpDitWoord>

en door middel van een soort van parser, de boel in de juiste array's te krijgen en hieruit je SQL te brouwen.

Ik wens je veel succes. Houdt ons op de hoogte en als deze reply niet met je vraag klopt, moet je hem ff iets duidelijker stellen want dit kon ik er van brouwen

[ Voor 0% gewijzigd door Glimi op 07-08-2002 09:07 . Reden: komma achter url :( ]

[whoami]

_Thanatos_ schreef op 06 augustus 2002 @ 23:28:
Als je MSSQL gebruikt als database, zou ik als ik jou was geen LIKE-clauses gebruiken, omdat die nooit gebruik maken van een index.

Off-topic, maar daar ga ik niet mee akkoord.
Een LIKE gebruikt imho wel een index (als die er ligt). Als je NOT LIKE gebruikt, zal er geen index gebruikt worden en als je LIKE '%E' doet, zal er imho ook geen index gebruikt worden.
(Volgens mij, niet getest).

[Glimi]

http://www.mysql.com/doc/en/MySQL_indexes.html

Hieruit haal je inderdaad dus dat als de expressie met een wildcard begint of geen constante is, er geen index op de LIKE gebruikt zal worden, echter in de andere gevallen wel. Bij NOT staat nergens een vermelding, plus dat een ontkenning van een constante imho nog steeds een constante is, dus zou je hierover een uitleg kunnen geven whoami?

[whoami]

Glimi schreef op 07 augustus 2002 @ 09:15:
http://www.mysql.com/doc/en/MySQL_indexes.html

Bij NOT staat nergens een vermelding, plus dat een ontkenning van een constante imho nog steeds een constante is, dus zou je hierover een uitleg kunnen geven whoami?

Van deze site: http://www.sql-server-per...query_analysis_tuning.asp

Carefully examine the WHERE clause. Is it sargable? In other words, can the WHERE clause take advantage of useful indexes? Some WHERE clauses include code that cannot take advantage of indexes, such as "IS NULL", "OR", "<>", "!=", "!>", "!<", "NOT", "NOT EXISTS", "NOT IN", "NOT LIKE", and "LIKE '%500'" can often (but not always) prevent the query optimizer from using an index to perform a search. In addition, expressions that include a function on a column, or expressions that have the same column on both sides of the operator, are not sargable.

[zoepercavia]

[half-offtopic mode]zorry jongens, ik ben gebonden aan access
voor zover ik weet heeft die geen support voor indexen...
[/half-offtopic mode]

glimi, het is wel ongeveer wat ik bedoel,
en ik wil inderdaad geen natural language parser maken
maar een syntax met +, - en " " lijkt me al even lastig genoeg (tenminste als het netjes moet). Ben vooral geinteresseerd in de 'theorie' erachter...

dus hoe zet je syntax om in een commando en dan tegelijkertijd flexibel om te gaan met foute syntax?

[whoami]

zoepercavia schreef op 07 augustus 2002 @ 12:14:
[half-offtopic mode]zorry jongens, ik ben gebonden aan access
voor zover ik weet heeft die geen support voor indexen...
[/half-offtopic mode]

Access, geen indexen??
Dan zul je toch eens beter moeten kijken hoor...

[Glimi]

zoepercavia schreef op 07 augustus 2002 @ 12:14:
glimi, het is wel ongeveer wat ik bedoel,
en ik wil inderdaad geen natural language parser maken
maar een syntax met +, - en " " lijkt me al even lastig genoeg (tenminste als het netjes moet). Ben vooral geinteresseerd in de 'theorie' erachter...

Niets theorie Glimi's grote duim was dit keer de ondersteuning

Maar zoals ik zei kun je het op twee manieren aanpakken: eerst indentificatie (dus indelen op groep dmv de operator, of indelen op entiteit en daarna verwerking toepassen.

dus hoe zet je syntax om in een commando en dan tegelijkertijd flexibel om te gaan met foute syntax?

Niet. Ik zou eerst je heel strikt aan de styntax houden en kijken wat je daar mee kan. Mocht je dat werkend hebben ga dan kijken naar ambïguiteit die mogelijk is bij menselijke input en hoe je dat wenst te interpeteren. Laat je broertje er achter zitten en laat hem op het keyboard rammen desnoods.

[Verwijderd]

ik zou heel snel access weg doen een sql server gebruiken... vervolgens Full Text Search gebruiken!

[ACM]

Maar ondanks dat men hier loopt te zeiken dat LIKE niet "the way to go" is, is het imho best een interessant vraagstuk hoe je vanuit zo'n zoekstring een behoorlijke query opstelt.

Of dat dan daarna met een koppeltabel, fulltext-searchengine of whatever wordt uitgevoerd, er zal altijd een query geformuleerd moeten worden.

[_Thanatos_]

Maar ondanks dat men hier loopt te zeiken dat LIKE niet "the way to go" is, is het imho best een interessant vraagstuk hoe je vanuit zo'n zoekstring een behoorlijke query opstelt.

Is niet zeiken, is adviseren
Maar, ik heb het weleens in ASP/MSSQL gedaan... het is opzich niet zo moeilijk. alle trefwoorden verzamelen met vlaggen erbij, in een array plempen en vervolgens de array doorlopen om de query te bouwen.

Topicstarter: je weet dat je Access niet per se via SQL hoeft aan te spreken? Misschien (kweet niet hoor, ik zeg maar wat) heeft Acces wel een fulltext-achtig mechanisme. Anders is het wel cool om zelf te bouwen