Re: problema con trigger

Por lo menos te puedo dar el feed back de Oracle, solo afecta y
notablemente el rendimiento sí el criterio de busqueda esta incluida
la función, y para solucionarlo se crea un indice por función,
postgresql me parece que lo soporta.

Ahora de meter el valor adentro del campo o no, solo ayudaria para
campos como IVA. (en el caso que cambie el IVA y no tener que escribir
funciones en base a tiempo para determinar Iva antes de tal fecha e
IVA despues de tal fecha, podría ayudar meter ese valor), pero A+B = C
y haciendo que dame los valores C > 10 (por ejemplo, es mejor
solucionar ese problema con el indice.. Ahora Alvaro o Jaime pueden
contestar con propiedad si es util un indice por función sí usas C en
el where como criterio de busqueda.

Es decir.

2010/10/28 JHONATAN CANO FURAGARO <jhonatan(dot)cano(dot)f(at)gmail(dot)com>:
> Buen día,
>
> Definitivanete, esto de gestionar y administrar un BD de  es muy amplia y
> tengo que pensar en muchas cosas a a ves que a la final la experiencia no se
> improvisa.
> Estoy aprendiendo, tuve la duda y se me van aclarando las cosas poco a poco.
>
> Trabajo actualmente con software para GIS (gvSIG), servidor de Mapas
> (Geoserver y Mapserver) con PSQL, entonces, los  mapas que hago para
> imprimir  y guardalos en PDF, la tabla la actualizo a medidas que el
> director del componente realiza cambios, los cuales se veran reflejados en
> el campo de zonificación. Este Campo lo usaré en Geoserver para ver la
> información en el servidor de mapas.
>
> Muchas gracias.
>
> 2010/10/27 Jaime Casanova <jaime(at)2ndquadrant(dot)com>
>>
>> 2010/10/27 Virginia <mavir78(at)gmail(dot)com>:
>> > Creo que el campo si debe ser incluído en la tabla pues al momento de
>> > manipular búsquedas o cualquier cosa por el campo total es más rápido
>> > que
>> > tener q realizar las ponderaciones y sumas al momento de buscar.
>> >
>>
>> tienes evidencia de que hay en realidad una mejora substancial en el
>> rendimiento? o solo asumes que como se van a realizar algunos calculos
>> debe ser mas rapido asi?
>>
>> Aunque posiblemente tengas razon que tener el campo calculado es mas
>> rapido, hay que considerar si la ganancia es mayor al problema de
>> tener que actualizar ese campo, asi como el espacio utilizado...
>>
>> Como dijo Donald Knuth: la optimizacion prematura es la raiz de todos los
>> males.
>>
>> --
>> Jaime Casanova         www.2ndQuadrant.com
>> Professional PostgreSQL: Soporte y capacitación de PostgreSQL
>
>
>
> --
> JHONATAN CANO FURAGARO
> Ingeniero Forestal
> Universidad Nacional de Colombia
> Celular 300 430 45 46
>

--
Saludos,
Horacio Miranda Aguilera.