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.

2 thoughts on “Despre MySQL si soundex”

  1. sau ai fi putut folosi Levenshtein intr-o procedura storata, ca tot te visezi din cand ca proceduri 🙂

  2. nu imi plac procedurile storate, pe urma ai logica dispersata peste tot, prefer sa o tin toata in cod si nu in baza.

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.