Búsqueda en texto con tildes

[Juan Pablo Martín Peinado]

Buenas, estoy haciendo unas búsquedas en una tabla mediante SELECT-SQL. Tengo el problema de que el usuario puede teclear el texto a buscar sin usar tildes y en la tabla esté con las tildes puestas (o viceversa) de manera que no lo encuentra.

Lo he medio solucionado convirtiendo todo a letras sin tildes de la siguiente manera:

lcTexto = "Bolígrafo"  && Es lo que ha podido teclear el usuario para buscar

ALLT(CHRTRAN(UPPER(lcTexto), "ÁÉÍÓÚ", "AEIOU"))  && Hago una conversión del texto a buscar

SELECT referencia, descripcion FROM articulos WHERE CHRTRAN(UPPER(descripcion), "ÁÉÍÓÚ", "AEIOU") = lcTexto  && Aquí también hago una conversión del texto que hay en la tabla.


El problema es que al utilizar CHRTRAN() y UPPER() la búsqueda se hace demasiado lenta.
Estoy utilizando índices con COLLATE GENERAL.

Saludos,

----------------------------------------------
Juan Pablo Martín Peinado
Guadalajara - España
----------------------------------------------

[Juan Pablo Martín Peinado]

Me respondo a mi mismo. Parece que la solución está en crear un índice así:

INDEX ON CHRTRAN(UPPER(descripcio),"ÁÉÍÓÚ","AEIOU") TAG descripcion

¿Hay alguna solución mejor?

----------------------------------------------

Juan Pablo Martín Peinado
Guadalajara - España
----------------------------------------------

[Fernando D. Bozzo]

Hola Juan Pablo:

El índice está bien con CHRTRAN(), lo que no es conveniente es que uses índices con collate GENERAL, ya que son más lentos que los MACHINE

Usando lo del CHRTRAN para los índices hace innecesario tener que usar collate GENERAL, además que incluso con ese collate, y pudiendo ver que te ordena los nombres bien "visualmente", luego no te sirve para las búsquedas, por lo que para la misma visualización te puede servir el índice CHRTRAN con collate MACHINE


Saludos.-

[Juan Pablo Martín Peinado]

Gracias Fernando, lo tendré en cuenta.

Hace años utilizaba los índices con MACHINE, pero los cambié porque en ocasiones no se visualizaban bien ordenados. Tengo una aplicación con más de 150 tablas y en todas, los índices son con collate GENERAL. No se si es buena idea que en algunos casos estén con GENERAL y en otros con MACHINE.

----------------------------------------------

Juan Pablo Martín Peinado
Guadalajara - España
----------------------------------------------

[Fernando D. Bozzo]

Un dato importante que tenés que tener en cuenta es que Rushmore solo funciona con indices de collate MACHINE, y esa optimización, bien usada, puede hacer diferencias de ejecución (consulta) de hasta 1000%.

[Juan Pablo Martín Peinado]

Desde luego que es para tenerlo en cuenta. La diferencia es importante. Ahora mismo quizás no lo notaría demasiado ya que las tablas afectadas no son muy grandes (unos 30.000 registros), pero con muchos más registros seguro que se tiene que notar la diferencia.

----------------------------------------------

Juan Pablo Martín Peinado
Guadalajara - España
----------------------------------------------

[Víctor Hugo Espínola Domínguez]

Si tienes VFP 9 debe funcionar esto:

LOCAL lcCollate, lcTexto

lcCollate = SET("Collate")

SET COLLATE TO "SPANISH"

lcTexto = "Bolígrafo%"

SELECT referencia, descripcion FROM articulos WHERE UPPER(descripcion) LIKE ?m.lcTexto

SET COLLATE TO (lcCollate)

Saludos,

Víctor.

Lambaré - Paraguay.

[Fernando D. Bozzo]

Hola Victor:

Lo del COLLATE solo sirve para crear indices, no para consultas.
Una vez creado el índice ya no se le puede cambiar el collate, se use como se use, salvo que lo borres y lo vuelvas a crear.

Para independizarse del SET COLLATE la instrucción INDEX ON tiene un parámetro especial llamado COLLATE "<valor>", que permite crear distintos indices con el COLLATE que se necesite

Saludos.-

[Víctor Hugo Espínola Domínguez]

Hola Fernando

Antes de postear hice la prueba creando índices con SET COLLATE TO MACHINE" y luego antes de una consulta SET COLLATE TO "SPANISH" y funciona OK, el efecto sobre los índices es que "Bolígrafo" y "Boligrafo" son diferentes con MACHINE e iguales con SPANISH. Otra ventaja de SET COLLATE TO "SPANISH" es que con un SELECT  ... ORDER BY Descripicon, "Bolígrafo" saldrá antes de "Bolindre".

El único pero que le encuentro a SET COLLATE TO "SPANISH" es que la RAE ya asesinó a las ex letras CH y LL y por ejemplo "Chamorro" saldra después de "Cuchicuchi" en un ordenamiento.

Saludos,

Víctor.

Lambaré - Paraguay.

[Juan Pablo Martín Peinado]

Fernando, he comprobado que el SET COLLATE si influye en el momento de hacer una consulta (SELECT-SQL).

Me explico, si en la tabla tengo creado el índice como COLLATE GENERAL y antes de hacer el SELECT-SQL pongo SET COLLATE TO "GENERAL", la respuesta es rápida, pero si pongo SET COLLATE TO "MACHINE" se vuelve lento.

----------------------------------------------
Juan Pablo Martín Peinado
Guadalajara - España
----------------------------------------------

[Fernando D. Bozzo]

Hola Juan Pablo:

Sí, es así, tal como comentó Víctor. Lo que no estoy muy seguro es si eso aprovecha Rushmore o no. Una cosa cosa es utilizar los índices y otra distinta es utilizar Rushmore con los índices, pero tampoco hay mucha información sobre eso.

Igualmente lo que es seguro, porque está documentado, es que los índices con COLLATcollate MACHINE son los más rápidos porque trabajan a nivel binario sin ningún tipo de conversiones ni adaptaciones lingüísticas ni de otro tipo.

Saludos!

[Fidel Charny]

Esto podría ser una alternativa. No sé que tán rápido es.

? SOUNDEX("Boligrafo") = SOUNDEX("bolígrafo")

[Fernando D. Bozzo]

Hay que tener en cuenta que SOUNDEX() mete 3 nuevos problemas en la ecuación:

1) Que está pensado para el Inglés solamente, aunque a veces acierte con algunas otras palabras
2) Que cada llamada implica una conversión al vuelo
3) Que por buscar palabras que "suenen" parecido, se puede caer incluso en más problemas que usando set NEAR ON, ya que, por ejemplo, en inglés "peera" suena como "pira" y te das cuenta que ni siquiera se parecen a nivel léxico.

Para el caso de la búsqueda de Nombres Propios, creo que la mejor solución es la de CHRTRAN(UPPER(string, "ÁÉÍÓÓ", "AEIOU")), ya que incluso usando un indice de collate GENERAL no te permite "buscar" la cadena indistintamente con o sin acentos, lo que creo que le quita un poco su utilidad, salvo que solo se use en un Browse para mostrar datos.

Qué raro que no hayan implementado nada para este tipo de búsquedas de forma nativa, con el uso mundial que tiene la herramienta desde su origen.

[Fidel Charny]

Entiendo Fernando. No sirve.
Con respecto a lo dicho por Juan Pablo

"Me explico, si en la tabla tengo creado el índice como COLLATE GENERAL y antes de hacer el SELECT-SQL pongo SET COLLATE TO "GENERAL", la respuesta es rápida, pero si pongo SET COLLATE TO "MACHINE" se vuelve lento."

Puede ocurrir que el SQL hace otro índice interno y por eso demora ?

[Fernando D. Bozzo]

Si, puede ser. De hecho creo que leí eso en algún lado de la ayuda.

[Luiz Alexandre Ruiz]

Uma outra forma, mas talvez deixe as tabelas grandes é criar o mesmo campo sem acento.

Nome e NomeSemAcento.