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.can...@gmail.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 <ja...@2ndquadrant.com> >> >> 2010/10/27 Virginia <mavi...@gmail.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. - Enviado a la lista de correo pgsql-es-ayuda (pgsql-es-ayuda@postgresql.org) Para cambiar tu suscripción: http://www.postgresql.org/mailpref/pgsql-es-ayuda
