2013-02-06 19 views
10

Era stato scritto molte volte già che la ricerca di base di OpenCart non è abbastanza buono .. Beh, ho sono imbattuto in questo problema:OpenCart - Cerca indipendentemente accento

Quando il cliente cerca prodotto nel mio paese (Slovacchia (UTF8)) probabilmente non userà segni diacritici. Quindi scrive "cucoriedka" e non trova nulla.

Ma, c'è un prodotto denominato "čučoriedka" nel database e voglio che venga visualizzato anche perché è quello che cercava.

Hai un'idea di come ottenere questo lavoro? Il semplice è, meglio è!

+0

aggiungere un'altra colonna e quindi aggiungere parole chiave alternative per il nome del prodotto. questo è solo un suggerimento! –

+0

Ci stavo pensando, ma ci sono molte possibilità per la parola. f.e. se sta trovando čučoriedka, potrebbe scrivere čucoriedka, cučoriedka, cucoriedka ... Non posso scrivere tutte le parole possibili nel database o con qualche script –

+0

akam ha detto la cosa giusta ..puoi aggiungere una colonna in più per questo e nello script durante la ricerca devi abbinare entrambi i valori dei campi. in modo che il tuo valore di ricerca corrisponda a čučoriedka o altro valore – jeeva

risposta

0

È possibile utilizzare la funzione SOUNDEX() o SOUNDS LIKE di MySQL.

Queste funzioni confrontano la fonetica.

La precisione di soundex è dubbia diversa dall'inglese. Ma, può essere migliorato se lo usiamo come

select soundex('ball')=soundex('boll') from dual 

SOUNDS LIKE può anche essere usato.

L'utilizzo della combinazione di entrambi SOUNDEX() e SOUNDS LIKE migliorerà la precisione.

gentilmente di fare riferimento documentazione di MySQL per i dettagli o mysql-sounds-like-and-soundex

+1

'SOUNDEX' è un antico algoritmo (brevettato nel 1918) sintonizzato appositamente per la localizzazione dei cognomi in inglese. Potrebbe non funzionare correttamente con i nomi di prodotti slovacchi. –

+0

Sì, hai assolutamente ragione. La precisione di soundex è dubbia per altri termini. ma, può essere migliorato se lo usiamo come 'select soundex ('ball') = soundex ('boll') da dual' – seahawk

+0

È una buona idea cambiare le regole di confronto delle colonne? 'ALTER TABLE product_description CHANGE nome nome VARCHAR (255) SET CARATTERE utf8 COLLATE utf8_general_ci NOT NULL;' Ho letto da qualche parte che la modifica delle regole di confronto potrebbe comportare il mancato utilizzo degli indici. È vero? – Adrian

5

Sono ignorante della slovacca, mi dispiace. Ma la collazione slovacca utf8_slovak_ci tratta la lettera slovacca č come distinta da c. (Fare i cognomi che iniziano con Č tutti venire dietro a quelli che iniziano con C nei vostri elenchi telefonici? Probabilmente lo fanno. I creatori di MySQL certamente pensano di fare.)

La raccolta utf8_general_ci tratta č e c lo stesso . Ecco un pasticcino che dimostra tutto questo. http://sqlfiddle.com/#!9/46c0e/1/0

Se si modifica la fascicolazione della colonna contenente il nome del prodotto per utf8_general_ci, si otterrà una tabella più ricerca-friendly. Supponiamo che il tuo tavolo sia chiamato product e che la colonna con il nome al suo interno sia chiamata product_name. Quindi questa istruzione di definizione dei dati SQL convertirà la colonna come richiesto. Si dovrebbe cercare il tipo di dati effettivo della colonna invece di utilizzare varchar(nnn) come ho fatto in questo esempio.

alter table product modify product_name varchar(nnn) collate utf8_general_ci 

Se non è possibile modificare la tabella, quindi è possibile modificare la clausola WHERE per lavorare in questo modo, specificando le regole di confronto in modo esplicito.

WHERE 'userInput' COLLATE utf8_general_ci = product_name 

Ma questa ricerca sarà più lenta rispetto alla modifica delle regole di confronto delle colonne.

Problemi correlati