El grupo al cual envías entradas es un grupo Usenet. Si envías mensajes a este grupo, cualquier usuario de Internet podrá ver tu dirección de correo electrónico
> estoy haciendo un programa que ha de buscar apellidos en una base de > datos. Me gustaría que en la búsqueda no se tuvieran en cuenta los > acentos.
> Me explico: > -si pongo Garcia me tendría que encontrar los apellidos Garcia y > García.
> ¿Sabe alguien como se puede hacer esto?
Seguramente hay varias opciones, podes hacer varios replace (uno por letra), podes usar translate o tambien podes usar algo como esto que surgio hace poco en la lista de PyAr:
>> Me explico: >> -si pongo Garcia me tendría que encontrar los apellidos Garcia y >> García.
>> ¿Sabe alguien como se puede hacer esto?
> Seguramente hay varias opciones, podes hacer varios replace (uno por > letra), podes usar translate o tambien podes usar algo como esto que > surgio hace poco en la lista de PyAr:
El problema de eso es que tienes que aplicar el post-procesado despues de hacer una query que te devuelva todos los resultados. Si hay pocos registros, no hay problema, pero eso no va a escalar.
En el lado de las BD, entiendo que MySQL permite especificar el "collation" de la BD. Eso podría ayudar.
En PostgreSQL, entiendo que no es posible explotar el "collation", pues no se puede especificar uno distinto por cada BD. Lo que se me ocurre es escribir el codigo de post-procesado (i.e, normalización) en alguno de los lenguajes de procedimientos almacenados de Postgres (entiendo que se pueden incluso escribir en Python!), y luego se podría aplicar un "functional index" para acelerar las queries que hagan comparaciones en que se aplique la funcion almacenada sobre la columna en cuestión.
En resumen: No tengo idea como resolver el problema el concreto, pero los keywords que puse más arriba pueden ser buenos puntos para explorar.
En el clean del formulario tanto de alta/modificación como de búsqueda
convierto todo a mayúsculas sin acentos (conservo Ñ y diéresis). De esta
manera, en la BD se almacena sólo así.
Otra posibilidad será almacenar el nombre y los apellidos sin acentos en 2
campos adicionales del modelo (puedes redefinir el método save del modelo) y
después realizar las búsquedas sobre estos campos.
Erny
El 30 de septiembre de 2008 3:29, Leo Soto M. <leo.s...@gmail.com> escribió:
> 2008/9/29 Facundo Casco <fca...@gmail.com>:
> > 2008/9/29 Franz <franz.jim...@gmail.com>:
> [...]
> >> Me explico:
> >> -si pongo Garcia me tendría que encontrar los apellidos Garcia y
> >> García.
> >> ¿Sabe alguien como se puede hacer esto?
> > Seguramente hay varias opciones, podes hacer varios replace (uno por
> > letra), podes usar translate o tambien podes usar algo como esto que
> > surgio hace poco en la lista de PyAr:
> El problema de eso es que tienes que aplicar el post-procesado despues
> de hacer una query que te devuelva todos los resultados. Si hay pocos
> registros, no hay problema, pero eso no va a escalar.
> En el lado de las BD, entiendo que MySQL permite especificar el
> "collation" de la BD. Eso podría ayudar.
> En PostgreSQL, entiendo que no es posible explotar el "collation",
> pues no se puede especificar uno distinto por cada BD. Lo que se me
> ocurre es escribir el codigo de post-procesado (i.e, normalización) en
> alguno de los lenguajes de procedimientos almacenados de Postgres
> (entiendo que se pueden incluso escribir en Python!), y luego se
> podría aplicar un "functional index" para acelerar las queries que
> hagan comparaciones en que se aplique la funcion almacenada sobre la
> columna en cuestión.
> En resumen: No tengo idea como resolver el problema el concreto, pero
> los keywords que puse más arriba pueden ser buenos puntos para
> explorar.
Creo que finalmente me quedaré con tu respuesta de los campos adicionales.
Como la búsqueda será con solo un campo en el que se pueda poner nombre o
apellidos indistintamente, crearé un nuevo campo que contenga todo (los
nombres y los apellidos), por los que se buscará, sin acentos.
Me parece la mejor opción a pesar de que se dupliquen algo los datos.
Muchas gracias a todos.
Franz
El 2 de octubre de 2008 15:10, Erny <ernesto.revi...@gmail.com> escribió:
> En el clean del formulario tanto de alta/modificación como de búsqueda
> convierto todo a mayúsculas sin acentos (conservo Ñ y diéresis). De esta
> manera, en la BD se almacena sólo así.
> Otra posibilidad será almacenar el nombre y los apellidos sin acentos en 2
> campos adicionales del modelo (puedes redefinir el método save del modelo) y
> después realizar las búsquedas sobre estos campos.
> Erny
> El 30 de septiembre de 2008 3:29, Leo Soto M. <leo.s...@gmail.com>escribió:
> 2008/9/29 Facundo Casco <fca...@gmail.com>:
>> > 2008/9/29 Franz <franz.jim...@gmail.com>:
>> [...]
>> >> Me explico:
>> >> -si pongo Garcia me tendría que encontrar los apellidos Garcia y
>> >> García.
>> >> ¿Sabe alguien como se puede hacer esto?
>> > Seguramente hay varias opciones, podes hacer varios replace (uno por
>> > letra), podes usar translate o tambien podes usar algo como esto que
>> > surgio hace poco en la lista de PyAr:
>> El problema de eso es que tienes que aplicar el post-procesado despues
>> de hacer una query que te devuelva todos los resultados. Si hay pocos
>> registros, no hay problema, pero eso no va a escalar.
>> En el lado de las BD, entiendo que MySQL permite especificar el
>> "collation" de la BD. Eso podría ayudar.
>> En PostgreSQL, entiendo que no es posible explotar el "collation",
>> pues no se puede especificar uno distinto por cada BD. Lo que se me
>> ocurre es escribir el codigo de post-procesado (i.e, normalización) en
>> alguno de los lenguajes de procedimientos almacenados de Postgres
>> (entiendo que se pueden incluso escribir en Python!), y luego se
>> podría aplicar un "functional index" para acelerar las queries que
>> hagan comparaciones en que se aplique la funcion almacenada sobre la
>> columna en cuestión.
>> En resumen: No tengo idea como resolver el problema el concreto, pero
>> los keywords que puse más arriba pueden ser buenos puntos para
>> explorar.
> Creo que finalmente me quedaré con tu respuesta de los campos adicionales. > Como la búsqueda será con solo un campo en el que se pueda poner nombre o > apellidos indistintamente, crearé un nuevo campo que contenga todo (los > nombres y los apellidos), por los que se buscará, sin acentos. > Me parece la mejor opción a pesar de que se dupliquen algo los datos. > Muchas gracias a todos. > Franz
Tal vez podrias considerar el uso de slugs. No se como se comportan exactamente con los acentos pero basicamente son cadenas de caracteres que contienen solo alfanumericos y guiones bajos. Django tiene un filtro para convertir a slug y un campo para guardarlos en la base de datos.
> En el clean del formulario tanto de alta/modificación como de búsqueda > convierto todo a mayúsculas sin acentos (conservo Ñ y diéresis). De esta > manera, en la BD se almacena sólo así.
> Otra posibilidad será almacenar el nombre y los apellidos sin acentos en 2 > campos adicionales del modelo (puedes redefinir el método save del modelo) y > después realizar las búsquedas sobre estos campos.
> > Yo lo he abarcado de otra manera anteriormente.
> > En el clean del formulario tanto de alta/modificación como de búsqueda
> > convierto todo a mayúsculas sin acentos (conservo Ñ y diéresis). De esta
> > manera, en la BD se almacena sólo así.
> > Otra posibilidad será almacenar el nombre y los apellidos sin acentos en 2
> > campos adicionales del modelo (puedes redefinir el método save del modelo) y
> > después realizar las búsquedas sobre estos campos.
> +1. Definitivamente sencillo y práctico!
Y para hacer la conversión, les recomiendo hacer una normalización
unicode:
A cada rato reviso el sitio www.django.es y es una pena que este tan desactualizado, muchos en la lista fueron capaces de la traducción del libro de Django (aplausos para todos ellos). Porque no le damos un poco de via a este sitio que a fin de cuenta puede ser el sitio de Django de la comunidad de habla hispana?
Si hacen algo, yo me apunto, para cosas puntuales. Pero hace falta alguien
que lidere el tema (yo, desgracidamente, no puedo, no tengo tiempo para
nada).
> A cada rato reviso el sitio www.django.es y es una pena que este tan
> desactualizado, muchos en la lista fueron capaces de la traducción del
> libro de Django (aplausos para todos ellos). Porque no le damos un poco
> de via a este sitio que a fin de cuenta puede ser el sitio de Django de
> la comunidad de habla hispana?
