Re: CONSEJO tablas grandes

No es sencillo, pero podes particionar la tabla para acelerar el
acceso (pero tendrias que asegurarte de usar algun indice para que
realmente disfrutes una sustancial mejora).

Si ya estas manejando este tipo de problemas te aconsejo que adquieras
un disco de alta velocidad, crees en el un tablespace y coloques alli
todos los indices de tu base.

Respecto a la estructura lógica de la información entre el apellido y
nombre, si todas las busquedas se basan en nombre y apellido, te
conviene tenerlas en un solo campo porque de esta manera las busquedas
de texto serian mucho mas rapidas al no tener que manejar varias
columnas.

El día 26 de noviembre de 2008 9:34, Javier Chávez B.
<jchavezb(at)gmail(dot)com> escribió:
> On Wed, Nov 26, 2008 at 11:19 AM, Gabriel Ferro
> <gabrielrferro(at)yahoo(dot)com(dot)ar> wrote:
>> 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%
>>
>> En realidad yo separo la cadena a buscar en subcadenas y luego para cada una hago un LIKE %subcadena%
>
> Tambien se puede de esa manera buscar : "Que comiense con.." / "que
> contenga" / "Que termine con.." si viene cierto no es comun este
> ultimo, entre mas le facilites la vida al usuario final es mejor...
>
> Siempre para mi es mejor separar los nombres y apellidos porque
> imaginate por ejemplo aqui en Portugal tienes nombres asi : "Fernando
> Eduardo Gama Costa Matos" o sea 3 apellidos... imagina una busqueda
> sobre ese string si esta en un solo campo, creo se vuelve lento ...
> ademas cuando necesitas ordenar para presentar un informe ,
> considerando que las digitaciones en terminos generales no son de las
> mejores, mas aun por ejemplo cuando tienes caracteres especiales "ç",
> "â", "ã" etc....
> Por lo mismo encuentro mucho mas eficiente , ordenado y me facilita
> mas la vida tener esos campos separados.
>
>> Ademas como no podemos definir un tamaño exacto para los campos uso un
>> nombre character varying(100)
>
> concuerdo contigo aun mas, yo le daria un poquito mas...
>
>> 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
>
> Eso tb es discutible porque es mejor por lo menos para mi siempre
> dejar un campo serial como id, ano ser que los datos obligatoriamente
> lo pidan, para mi es mejor dejar un indice con esos campos que
> controle que sean unicos y que me aumenten el desempeño en las
> busquedas.
>
>> ademas numdoc no puede ser in entero largo debe ser character (12), porque en cualquier comento le agregan letras..
>
> Exactamente concuerdo contigo pasa lo mismo por ejemplo un tiempo
> atras tuve que hacer un control de camiones donde tenia que guardar
> la patente y en chile era XX-9999 y lo normal era dejar un string de 6
> o 7, pero el registro civil cambio eso o tenia un plan de cambio para
> XXXX-9999 por lo tanto tuve que dejarlo un poco mayor preparandose
> para el futuro...
>
>
>> 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..
>
> Aumenta el tamaño pero te facilita la vida....
>
> Slds.
>
> J.
>
>
> --
> Cumprimentos
> jchavez
> linux User #397972 on http://counter.li.org/
> --
> TIP 8: explain analyze es tu amigo
>

--
Emanuel Calvo Franco
Syscope Postgresql Constultant
ArPUG / AOSUG Member