From: | Diego Gil <diego(dot)gil(at)maipucinos(dot)com(dot)ar> |
---|---|
To: | <pgsql-es-ayuda(at)postgresql(dot)org>, Gabriel Ferro <gabrielrferro(at)yahoo(dot)com(dot)ar> |
Subject: | Re: Re: CONSEJO tablas grandes |
Date: | 2008-11-26 13:02:13 |
Message-ID: | 48554.1227704533@maipucinos.com.ar |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-es-ayuda |
On Wed 26/11/08 08:19 , Gabriel Ferro gabrielrferro(at)yahoo(dot)com(dot)ar sent:
> Por el tema nombre+apellido, les comento que muchas veces la cosa no es tan
> sencilla YEDRO distinto HYEDRO pero suena igual aveces solo se tiene un
> nombre y otras no se recuerda si era marcelo, marcelino o algo asi... asi
> que debemos buscar %yedro% y %marce%
>
Estimo que el tener los campos separados te aceleraria la mayoría de las búsquedas (marcel%) y en los casos de excepción como el que mencionás se pueden hacer las mismas búsquedas que mencionás (%marcel%), más lerdas. Cosa que se justificaría porque son las excepciones, los casos menos frecuentes.
Una vez estuve explorando el tema de nombres parecidos, por como suenan. Hay una funcion SOUNDEX que en ciertas aplicaciones anda bastante bien. La usé con otras bases de datos pero creo que hay algo para postresql también. El tema es que generalmente está orientada más al idioma inglés. Con esta función se podría acceder a la palabras que suenan similar aun cuando su escritura sea distinta. El tema es afinar que se entiende por similar en castellano.
>
> En realidad yo separo la cadena a buscar en subcadenas y luego para cada
> una hago un LIKE %subcadena%
>
>
>
>
> Ademas como no podemos definir un tamaño exacto para los campos uso un
>
> nombre character varying(100)
>
>
Según yo entiendo, en postgresql un campo character variyng(100) es practicamente lo mismo que un campo text, solo que se controla el largo. O sea que si no hay interés en limitar el largo del dato ingresado o no se conoce el tamaño, es mejor definirlo como text. Internamente se comporta igual aparentemente.
>
> y creo que jamas este campo puede ser una clave para la tabla tengo muchos
> casos con personas conj mobres y apellidos exactamente iguales....se
> imaginan se informo que es un caco fugado cuando en realidad es
> otro...jeee... pobre tipo.... asi que uso como key tipodoc+numdocumento
>
Puede no ser candiato para una clave primaria, pero seguramente será necesario crear un índice sobre ese dato. Se pueden tener indices con valores repetidos, solo es necesario no indicar UNIQUE.
>
> ademas numdoc no puede ser in entero largo debe ser character (12), porque
> en cualquier comento le agregan letras..
>
>
> Asi que el tamaño de la tabla puede ser muyyyyy grande... y si lo divido
> en dos seguro que aumenta el tamaño de la tabla.... puff..
>
No puedo demostrarlo, pero tengo la idea que si se separan los nombres y apellidos en campos distintos el tamaño de la tabla no aumenta mucho. Alvaro, podrías explicarnos esto mejor ?.
Saludos,
Diego.
From | Date | Subject | |
---|---|---|---|
Next Message | juan | 2008-11-26 13:14:00 | Tamaño de un varchar en la base de datos. |
Previous Message | Ernesto Lozano | 2008-11-26 13:01:22 | Re: 911 |