[PHP][MYSQL] Query LIKE met php variable

[Swanfield]

Het lukt mij niet om een query te kunnen maken met de LIKE optie.

De volgende query heb ik:

$value = 'De straat heet Zwabberdam 18'
("Select * FROM straatnaam Where straatnaam LIKE '%".$value."%'");

Nu wil ik dus dat hij checkt in de database of Zwabberdam in $value staat en dat als resultaat dan ook toont.
Als ik dus de waarde bij $value Zwabberdam maakt dan krijg ik wel resultaat te zien.
Wat die ik fout?

[Hydra]

Je snapt niet hoe like werkt. Like zoekt naar een string waarin $value een substring is. "De straat heet Zwabberdam 18" is geen substring van "zwabberdam", hij zoekt niet naar in van de woorden ofzo.

http://dev.mysql.com/doc/...ctions.html#operator_like

[ Voor 18% gewijzigd door Hydra op 08-11-2012 12:03 ]

[GlowMouse]

Kijk eens naar de MySQL-functie INSTR. Je moet alleen niet verwachten dat je query snel draait wanneer je heel Nederland erin hebt zitten. Een alternatief is om je $value per woord op te splitsen, en dan op elk los woord te controleren.

[ Voor 26% gewijzigd door GlowMouse op 08-11-2012 12:04 ]

[Swanfield]

En kan ik dat niet anders oplossen dan?

GlowMouse schreef op donderdag 08 november 2012 @ 12:03:
Kijk eens naar de MySQL-functie INSTR. Je moet alleen niet verwachten dat je query snel draait wanneer je heel Nederland erin hebt zitten.

Ok tnx zal het eens bekijken

[ Voor 79% gewijzigd door MueR op 08-11-2012 13:28 ]

[Hydra]

Welk probleem probeer je precies op te lossen? Dus gewoon ffn een uitleg van wat je aan 't doen bent. Wat jij wil doen schaalt enorm slecht namelijk.

[Swanfield]

Hydra schreef op donderdag 08 november 2012 @ 12:07:
Welk probleem probeer je precies op te lossen? Dus gewoon ffn een uitleg van wat je aan 't doen bent. Wat jij wil doen schaalt enorm slecht namelijk.

Ik krijg uit een rss feed een regel tekst waar ondermeer de straatnaam in voorkomt. Deze wil ik dus checken in een database om te zien of in de tekst een straatnaam staat en zo ja deze dan te tonen.

[jbdeiman]

Heb je in die feed regel altijd "De straat heet" ervoor staan? Zo ja, dan dit vervangen door niks (lege string) en nog even trim om de straatnaam heen gooien om loze spaties te droppen. Je krijgt dan alleen een probleem met het huisnummer.

Hoe krijg je precies die data (adresgegevens) terug uit de RSS?

[Swanfield]

jbdeiman schreef op donderdag 08 november 2012 @ 12:13:
Heb je in die feed regel altijd "De straat heet" ervoor staan? Zo ja, dan dit vervangen door niks (lege string) en nog even trim om de straatnaam heen gooien om loze spaties te droppen. Je krijgt dan alleen een probleem met het huisnummer.

Hoe krijg je precies die data (adresgegevens) terug uit de RSS?

Nee helaas is de waarde die voor de straatnaam staat heel erg veranderlijk. Dus ipv voor iedere uitzondering een regel te maken dacht ik, als ik nu in die regel kan kijken of de waardes overeenkomen dan kan ik dat echo'en.

[Hydra]

Hoe lang is die lijst plaatsnamen? Als die niet extreem lang zou ik dat eerder gewoon in je applicatie doen.

[P.O. Box]

of je draait de argumenten van je LIKE om...

[MueR]

Evengoed schaalt dat brak. Zodra je DB wat groter wordt gaan die queries heel lang duren.

[Swanfield]

Als ik de query gewoon uitvoer met een vaste waarde dus Zwabberdam = Zwabberdam bijvoorbeeld dan heb ik gewoon snel resultaat. Dus volgens mij qua performance heb ik geen probleem.
Omdraaien helpt helaas ook niet..

[MueR]

Swanfield schreef op donderdag 08 november 2012 @ 14:00:
Als ik de query gewoon uitvoer met een vaste waarde dus Zwabberdam = Zwabberdam bijvoorbeeld dan heb ik gewoon snel resultaat. Dus volgens mij qua performance heb ik geen probleem.
Omdraaien helpt helaas ook niet..

Snel resultaat met een exacte match is ook niet moeilijk.. Hoeveel records heb je nu in die database staan? Max 1000? Zodra je met wildcards op grote databases (en 1000 is peanuts) gaat vergelijken gaat die perfomance dramatisch kelderen. Trust me.

[Swanfield]

MueR schreef op donderdag 08 november 2012 @ 14:17:
[...]

Snel resultaat met een exacte match is ook niet moeilijk.. Hoeveel records heb je nu in die database staan? Max 1000? Zodra je met wildcards op grote databases (en 1000 is peanuts) gaat vergelijken gaat die perfomance dramatisch kelderen. Trust me.

Nou het zijn er wel iets meer... 412099.

[Blamm]

Wanneer je niet het woord 'Zwabberdam' uit de string vanuit de rss kunt filteren, maar alle woorden gaat vergelijken, gaat het sowieso niet lekker werken ben ik bang.

Wat denk je namelijk dat er gebeurt wanneer je gaat kijken of er een plaatsnaam in de database voorkomt met de string "de" in de naam voorkomt? Heel erg veel, irrelevante, resultaten.

[Swanfield]

Blamm schreef op donderdag 08 november 2012 @ 14:42:
Wanneer je niet het woord 'Zwabberdam' uit de string vanuit de rss kunt filteren, maar alle woorden gaat vergelijken, gaat het sowieso niet lekker werken ben ik bang.

Wat denk je namelijk dat er gebeurt wanneer je gaat kijken of er een plaatsnaam in de database voorkomt met de string "de" in de naam voorkomt? Heel erg veel, irrelevante, resultaten.

Hmm ja daar heb je inderdaad een punt
Moet maar eens kijken hoe ik dat beter kan oplossen.

[Blamm]

Hoe erg verschillend zijn de teksten die vanuit de RSS binnenkomen? Volgen deze een vast stramien, of is het echt "van alles en nog wat"?

Indien je toch woord voor woord wilt gaan vergelijken, is het misschien slim om niet

PHP:

$query = "SELECT * FROM straatnamen WHERE naam LIKE '%" . $value . "%'";

maar

PHP:

$query = "SELECT * FROM straatnamen WHERE naam LIKE '" . $value . "'";

te gebruiken.
Je wilt (aanname van mij hoor) geen hit op "terdam", maar op "Amsterdam"

edit:

En vergeet niet te escapen, zeker wanneer de tekst vanuit een externe bron komt. Zoals de query hierboven staat is het een disaster waiting to happen

[ Voor 14% gewijzigd door Blamm op 08-11-2012 15:05 ]

[Merethil]

Beginnen alle steden in de RSS wel met een hoofdletter?
Aangezien een groot deel van de steden toch niet begint met iets als s' of 's ofzo, kan je daar al een deel op filteren. Nog steeds flink gevaarlijk, maar een stuk beter dan op elk los woord checken.

[Verwijderd]

Merethil schreef op donderdag 08 november 2012 @ 15:12:
Beginnen alle steden in de RSS wel met een hoofdletter?
Aangezien een groot deel van de steden toch niet begint met iets als s' of 's ofzo, kan je daar al een deel op filteren. Nog steeds flink gevaarlijk, maar een stuk beter dan op elk los woord checken.

Als ik het goed begrepen heb wil Swanfield zoeken op straatnaam, niet op stad/dorp/gemeente/woonplaats/...

[Hydra]

Swanfield schreef op donderdag 08 november 2012 @ 14:58:
Hmm ja daar heb je inderdaad een punt
Moet maar eens kijken hoe ik dat beter kan oplossen.

Zoals ik al zei; je wil voor elke straat in je lijst kijken of 'ie in de tekst voorkomt, niet andersom. Dit moet je dus in je applicatie oplossen.

[Gomez12]

Staat er in elke rss een straatnaam?

Want dan zou je volgens mij nog redelijk efficient kunnen zoeken door simpelweg je tekst op te splitsen in woorden en dan via een simpel algoritme (eindigt op straat = ++, eindigt op dam = ++, langer dan 8 tekens = ++ ) etc de meest waarschijnlijk woorden als eerste kunnen matchen naar straten.

Simplistisch alternatief wat ik wel eens eerder heb gezien : Mieter alles in een full-text search engine en laat die je complete string zoeken met zijn algoritmes en ga dan naar de dbase met die resultaten.

[Hydra]

Dat heeft geen enkel nut omdat er zoveel straten zijn zonder straat of dam e.d. (hele wijken zijn naar kruiden genoemd e.d.) zijn, dus je moet gewoon brute force ieder woord met een lijst vergelijken.

[Merethil]

Verwijderd schreef op donderdag 08 november 2012 @ 15:33:
[...]

Als ik het goed begrepen heb wil Swanfield zoeken op straatnaam, niet op stad/dorp/gemeente/woonplaats/...

Alhoewel ik moet zeggen dat ik fout zat: Maakt het veel verschil? Straatnamen/dorpen/gemeenten/woonplaatsen beginnen in de regel allemaal met hoofdletters.

Hoe dan ook: Ik zou een combinatie van allerlei aanpakken nemen: Woordlengte, eindigt op "straat/laan/dam/plein/whatever", begint met een hoofdletter.
Zodra je dit alles samenvoegt is het iig al een heel stuk sneller dan elk woordje door je database halen om te kijken of "de" in je straatnamenlijst staat.

[Hydra]

Merethil schreef op donderdag 08 november 2012 @ 16:41:
[...]


Alhoewel ik moet zeggen dat ik fout zat: Maakt het veel verschil? Straatnamen/dorpen/gemeenten/woonplaatsen beginnen in de regel allemaal met hoofdletters.

Hoe dan ook: Ik zou een combinatie van allerlei aanpakken nemen: Woordlengte, eindigt op "straat/laan/dam/plein/whatever", begint met een hoofdletter.
Zodra je dit alles samenvoegt is het iig al een heel stuk sneller dan elk woordje door je database halen om te kijken of "de" in je straatnamenlijst staat.

Dit zijn typisch van die aannames die gewoon leiden tot slechte software. Het is een RSS feed dus je kunt er absoluut niet vanuit dat het met een hoofdletter geschreven is, en er zijn heel veel straatnamen die niet op -straat of wat dan ook eindigen. Ik heb vroeger in een wijk gewoond waar de straten gewoon "Vroegeling", "Anemoon" en "Madelief" heten.

[Swanfield]

Wat ik nu heb is if(strpos($locatie, $straat) !== false)
Waar dan de $locatie de lange string is en $straat ui de database komt. Inderdaad heb je dan het probleem dat er meerdere hits uit komen dus een goede oplossing is het nog niet. Ook duurt het even eer het geladen is inderdaad maar ook dat kan ik nog filteren om alleen de straten van de stad te nemen die ik nodig heb Maar afijn het is een heel karwij en ben iets dichterbij wat ik zoek.

[Cartman!]

Heel veel straatnamen komen wel vaker voor (denk aan Hoogstraat, Stationsplein, Markt), wat voor data is het precies die je bij die entry in de feed wilt opzoeken?

[Gomez12]

Hydra schreef op donderdag 08 november 2012 @ 16:40:
Dat heeft geen enkel nut omdat er zoveel straten zijn zonder straat of dam e.d. (hele wijken zijn naar kruiden genoemd e.d.) zijn, dus je moet gewoon brute force ieder woord met een lijst vergelijken.

Wat is volgens jou het voordeel van compleet brute forcen boven een simpel rangschikkingsalgoritme wat je brute force mogelijkheden kan verminderen?

Ik bedoel als je in je db alleen maar entries hebt staan van min 6 tekens lang, wil jij dan toch echt alles kleiner dan 6 tekens gaan bruteforcen (want stel dat er spontaan een entry in je db bijkomtoid)

In worst case moet je met een rangschikking alsnog alles gaan brute forcen , best case is simpelweg de 1e poging juist.

Nou is bij 412099 records alles brute forcen nog geen ramp maar komen er meer straten bij dan ga je met simpelweg alles brute forcen toch eerder tegen een limiet aanlopen dan met een simpel rangschikking en voorselectie algoritme.

[RobIII]

MueR schreef op donderdag 08 november 2012 @ 14:17:
Trust me.

En als je MueR niet op z'n blauwe ogen wil vertrouwen heb ik een mooie analogie voor je. Neem een telefoonboek. Zoek daarin binnen een willekeurige stad uit dat boek (zeg: Amsterdam) alle Janssens. Simpel klusje hé? Zou je niet meer dan een paar seconden tot hooguit een minuut moeten kosten. Gefeliciteerd: je weet nu (in essentie) wat een index is. Zoek nu even alle namen waarin "van der" voorkomt. In die case ga je met een gewone LIKE gewoon een full table scan moeten doen; ofwel: het telefoonboek voor die stad van A tot Z moeten uitpluizen, naam-voor-naam. Gefeliciteerd: u bent nu een gevorderd index beginner

Voor namen die eindigen op "...ssen" kun je nog een truukje uithalen en met wat denormalisatie simpel zoeken met een LIKE, maar dan gaat de telefoonboekanalogie stuk want daar heb je niet de luxe even makkelijk een tweede veldje + index te maken

Het volstaat, als dit allemaal nieuw voor je is, voorlopig als simpele rule-of-thumb te hanteren dat X = Y en LIKE 'X%' ("Janssen", "Jans%") een index kunnen gebruiken _{(mits aanwezig)} en dat performed goed. De LIKE '%X' en LIKE '%X%' ("%ssen", "%sse%") kunnen dat niet en dat performed...bagger

[ Voor 40% gewijzigd door RobIII op 09-11-2012 01:34 ]

[Verwijderd]

Gomez12 schreef op donderdag 08 november 2012 @ 16:38:
Simplistisch alternatief wat ik wel eens eerder heb gezien : Mieter alles in een full-text search engine en laat die je complete string zoeken met zijn algoritmes en ga dan naar de dbase met die resultaten.

Quoted for emphasis.
Dit kan best weleens goed uitpakken, zeker als de search engine een bepaalde fouttolerantie heeft. Niet iedereen spelt zijn eigen straatnaam correct

[pedorus]

Dit is natuurlijk geen echt onoplosbaar performance probleem op een normale pc. Neem x, het maximaal aantal spaties dat in een straatnaam voorkomt. Die 412099 straatnamen passen makkelijk in het geheugen van een willekeurige moderne pc, met een hashmap kunnen we hierin zoeken met O(1). Je splits de string waarin je wilt zoeken op spaties, en je zoekt vervolgens voor 1,2,..., x woorden achter elkaar of dit in je hashmap voorkomt. Klaar....

Vervolgprobleem: sommige straatnamen matchen te vaak, wat nu?

Vervolgprobleem 2: spelfouten zoals hierboven. Kijk eens naar bijv. lucene/solr hoe ze het daar oplossen.

[Hydra]

Gomez12 schreef op vrijdag 09 november 2012 @ 01:06:
Wat is volgens jou het voordeel van compleet brute forcen boven een simpel rangschikkingsalgoritme wat je brute force mogelijkheden kan verminderen?

Ah, op die fiets. Dan had ik je gewoon verkeerd begrepen.

Nou is bij 412099 records alles brute forcen nog geen ramp maar komen er meer straten bij dan ga je met simpelweg alles brute forcen toch eerder tegen een limiet aanlopen dan met een simpel rangschikking en voorselectie algoritme.

Hij filtert al op plaatsnaam eerst, dus je houdt veel minder straten over.

[P.O. Box]

RobIII schreef op vrijdag 09 november 2012 @ 01:22:
[...]


Het volstaat, als dit allemaal nieuw voor je is, voorlopig als simpele rule-of-thumb te hanteren dat X = Y en LIKE 'X%' ("Janssen", "Jans%") een index kunnen gebruiken _{(mits aanwezig)} en dat performed goed. De LIKE '%X' en LIKE '%X%' ("%ssen", "%sse%") kunnen dat niet en dat performed...bagger

%ssen kun je nog oplossen door een kolom in je tabel toe te voegen met de revert van de naam... en daar dan een index op te maken

[Swanfield]

Waar haal je deze info vandaan? Voor zover ik kan zien gaat het nog steeds om de rss in de TS en daar staat geen plaatsnaam bij (of de rss moet plaatsgebonden zijn)

En stiekem gaat dat dan de volgende uitdaging zijn, de damstraat of kerkstraat oid zal 100x voorkomen, net zoals kerkpad etc. etc.
Veel succes met het koppelen aan de de juiste straat als je niet meer info hebt.

Uit een opensource database die ik in MySQL heb geschoten. Op Stadsnivo kom ik top op heden nog niet dubbele straatnamen tegen. Echter zou ik nog met postcode gebied e.d. kunnen werken om dat te tackelen.

[ Voor 74% gewijzigd door Swanfield op 09-11-2012 10:10 ]

[Gomez12]

Hydra schreef op vrijdag 09 november 2012 @ 09:54:
[...]
Ah, op die fiets. Dan had ik je gewoon verkeerd begrepen.

Tja, het inzetten als filteringsmechanisme is idd gedoemd om tot problemen te leiden.

[...]
Hij filtert al op plaatsnaam eerst, dus je houdt veel minder straten over.

Waar haal je deze info vandaan? Voor zover ik kan zien gaat het nog steeds om de rss in de TS en daar staat geen plaatsnaam bij (of de rss moet plaatsgebonden zijn)

En stiekem gaat dat dan de volgende uitdaging zijn, de damstraat of kerkstraat oid zal 100x voorkomen, net zoals kerkpad etc. etc.
Veel succes met het koppelen aan de de juiste straat als je niet meer info hebt.
Niet meer relevant

[RobIII]

P.O. Box schreef op vrijdag 09 november 2012 @ 10:04:
[...]


%ssen kun je nog oplossen door een kolom in je tabel toe te voegen met de revert van de naam... en daar dan een index op te maken

Dat zeg ik

RobIII schreef op vrijdag 09 november 2012 @ 01:22:
Voor namen die eindigen op "...ssen" kun je nog een truukje uithalen en met wat denormalisatie simpel zoeken met een LIKE, maar dan gaat de telefoonboekanalogie stuk want daar heb je niet de luxe even makkelijk een tweede veldje + index te maken

[P.O. Box]

RobIII schreef op vrijdag 09 november 2012 @ 10:15:
[...]

Dat zeg ik

[...]

oops... overheen gelezen... kleine lettertjes en ik zijn een gevaarlijke combinatie (voor mezelf)..