Despre MySQL si soundex

Deci MySQL … Sincer sa fiu, in disputele religioase MySQL vs PostgreSQL, sunt de obicei de partea Postgres, dar fortat de imprejurari in general trebuie sa utilizez MySQL (impotriva bunului meu simt, of course). Anyway, pana acum nu am avut motive chiar asa serioasa sa ma irite MySQL. Pana acum.

De curand intr-un proiect care-l “repar”, aveam o pagina care lista niste aeroporturi in functie de inputul utilizatorului. De exemplu daca introduceai “paris”, respectiva pagina iti lista cele cateva aeroporturi din paris si inca vreo 7 – 8 din lume care erau “asemanatoare” ca nume.

Problema e ca rezultatele erau foarte aiurea in unele cazuri, si nu intelegeam de ce. O scurta privire in codul primitiv si prostesc care domneste in acest proiect mi-a dezvaluit modul destul de simplu in care se facea operatiunea:

in baza de date o tabela stoca o lista de aeroporturi care avea in nume si orasul (utilizatorul urma sa caute dupa oras), si folosind functia SOUNDEX, lista toate inregistrarile alea carui SOUNDEX era identic cu cel al stringului cautat. Destul de normal .. aparent.

SELECT ID,Code,City, Airport, Country FROM airports WHERE Soundex(City) = SOUNDEX(\”$deptArpt\”)

Problema e ca “baietii de la mysql” au hotarat ca nu are sens sa urmeze algoritmul de soundex din manual, ei sunt mai destepti si algoritmul lor nu se opreste dupa 3 numere identificate, ci merge pana la sfarsit. Ideea pare ok, pana iti dai seama ca in felul asta “new york airport” si “new york” au scoruri diferite, which really sux. De aici veneau problemele – soundex este destul de inutil in forma lui initiala.
O posibila rezolvare ar fi sa pastrez doar primele 3 numere si sa le ignor pe restul, ceea ce am si facut. Insa inainte am calculat toate soundex-urile intr-un camp suplimentar  (soundscore) pentru a usura load-ul in timpul functionarii.
O alta problema a fost “similitudinea”. Un SGBD inteligent ca Postgres are o functie care se cheama similarity si care iti returneaza un scor care il poti folosi pentru a regla cate rezultate primesti. MySQL … normal ca nu are asa ceva. Eu aveam nevoie si de acest comportament, asa ca am scos prima litera din rezultatul soundex (care arata ceva de genul P345, unde P e prima litera a stringului), si am facut o comparatie a diferentei intre scorul initial si scorul stringului cautat.
Adica ceva cam asa:

select ID,Code,City, Airport, Country from airports where ABS(CAST(substring(soundex(\”$deptArpt\”), 2) as SIGNED) – soundscore) < 5 AND substring(soundex(\”$deptArpt\”), 1, 1) = soundletter

Ultima comparatie este necesara pentru ca prima litera este esentiala in acest tip de cautare.
Bun asta cam imi rezolva problema, pot stoca rezultatele in soundscore pentru ca lista de aeroporturi este statica. Oricum … MySQL … pula mea …varza.

GET si POST

Postul asta ar trebui citit in primul rand de “baietii de la wordpress”. Se pare ca ei nu au auzit de faptul ca & este folosit in stringul GET ca separator, cel putin de php in care aparent e scris wordpress-ul.

So, daca va uitati parola cumva si dati click pe “lost password”, sunt anumite sanse ca, algoritmul inteligent din spate ca genereaza o cheie random, sa genereze printre caractere si &.
Solutia? Editez in baza de date cheia utilizatorului, ii scot & si intru pe linkul de resetare cu & scos.
Daca va intrebati de ce nu am rescris pur si simplu parola din phpmyadmin, motivul e ca, la prima vedere stringul de acolo nu parea md5 (nu avea lookul de md5), deci mi s-a parut ca probabil folosesc un algoritm custom (sper ca macar e o transformare ireversibila ca md5, nu m-ar mira nimic).