2010/10/27 Horacio Miranda :
>
> 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 valo
Excerpts from Horacio Miranda's message of mié oct 27 19:38:35 -0300 2010:
> 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
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 par
Gracias a todos por sus comentarios, lo solucioné cambiando el tipo
smallint por integer
Saludos
Mario Soto
2010/10/27, Jenaro Centeno Gómez :
> En realidad viendo la definición de la función y el error que te
> devuelve se puede ver que no estas llamando la función con los mismos
> parámetros c
En realidad viendo la definición de la función y el error que te
devuelve se puede ver que no estas llamando la función con los mismos
parámetros con los que la creaste, recuerda que en PostgreSQL puedes
manejar varias funciones con el mismo nombre (sobrecarga).
Saludos.
El 27/10/10 12:18 p.m
2010/10/27 Alvaro Herrera :
> Excerpts from mas...@gmail.com's message of mié oct 27 11:07:04 -0300 2010:
>> Alvaro, muy buena explicación acerca de los tipos, pero disculpen mi
>> insistencia el porque en un insert normal esta situación no se
>> produce, pero en una función si se dá éste problema
2010/10/27 Gaston Rider :
> Buenos Días:
>
> Vengo de SQL-Server, allì habìa una herramienta que la utilizaba
> cotidianamente (SQL Server Profiler), la cuál mostraba todas las querys que
> procesaba el motor. Tambièn daba la información del tiempo que insumió la
> misma, usuario, fecha etc. Todo e
Excerpts from mas...@gmail.com's message of mié oct 27 11:07:04 -0300 2010:
> Alvaro, muy buena explicación acerca de los tipos, pero disculpen mi
> insistencia el porque en un insert normal esta situación no se
> produce, pero en una función si se dá éste problema
Lo voy a investigar y te cuento
Alvaro, muy buena explicación acerca de los tipos, pero disculpen mi
insistencia el porque en un insert normal esta situación no se
produce, pero en una función si se dá éste problema
Saludos cordiales
Mario Soto
El 27/10/10, Alvaro Herrera escribió:
> Excerpts from Jaime Casanova's message of
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
Excerpts from Jaime Casanova's message of mié oct 27 10:39:40 -0300 2010:
> te contesto si me contestas una pregunta simple. que tipo de dato
> corresponde al valor siguiente: 5
> un numero sin cast explicito no tiene un contexto claro asi que
> postgres asume integer
De hecho es todo un tema sa
Hola Jaime, entiendo lo que dices, pero sigo sin entender porque un
insert normal no da el error de los smallint y si los da un insert en
una función.
Saludos
Mario Soto
El 27/10/10, Jaime Casanova escribió:
> 2010/10/27 mas...@gmail.com :
>> En efecto, el problema son los campos de tipo smalli
2010/10/27 mas...@gmail.com :
> En efecto, el problema son los campos de tipo smallint, lo que no
> entiendo es si postgreSQL, soporta éste tipo de datos ¿porque ocaciona
> errores al utilizarlos en funciones y no así en un insert
> convencional?
>
te contesto si me contestas una pregunta simple.
2010/10/27 Virginia :
> 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 substanc
Excerpts from Virginia's message of mié oct 27 10:04:57 -0300 2010:
> 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.
¿Consideraste
Hola Jhonatan, si los valores de ponderación para la suma ponderada,
responden a una fórmula estática, es decir no se modifican nunca, entonces
no es necesario que almacenes zonificación.
Despues podrás crear una vista mas o menos así:
select campo1, campo2, campo3, campo1*peso1 + campo2*peso2 + ca
Excerpts from JHONATAN CANO FURAGARO's message of mié oct 27 09:58:51 -0300
2010:
> Buen día Guillermo,
>
> Gracias por tu pronta respuesta, tendre en cuenta las vistas y funciones.
>
> Pero por ejemplo, tengo una capa en PostgreSQL/PostGIS, donde tengo campo1,
> campo2, campo3 y zonificacion, d
En efecto, el problema son los campos de tipo smallint, lo que no
entiendo es si postgreSQL, soporta éste tipo de datos ¿porque ocaciona
errores al utilizarlos en funciones y no así en un insert
convencional?
Saludos y Gracias a todos
Mario Soto
El 27/10/10, Alvaro Herrera escribió:
> Excerpts
En efecto el error es en los tipos smallint, lo que no entiendo es lo
siguiente : si puedo modelar utilizando éstos tipos de datos ya que
postgre
El 27/10/10, Alvaro Herrera escribió:
> Excerpts from mas...@gmail.com's message of mar oct 26 16:12:44 -0300 2010:
>> Hola Jaime,
>>
>> el error me lo
Hola Jhonatan, creo que tu caso es igual q el mio.
En mi caso, les digo a los de la lista que no creo q se trate de un mal
diseño, pues para acortar la explicación los campos que se deben sumar no
son con valores directos, es decir, si en la tabla promedios (de mi ejemplo)
el campo1 tiene un valor
Excerpts from mas...@gmail.com's message of mar oct 26 16:12:44 -0300 2010:
> Hola Jaime,
>
> el error me lo dá precisamente en los campos char y varchar y eso es
> lo que no entiendo
¿A qué te refieres con que el error te lo da en campos char y varchar?
El mensaje de error no menciona ningún cam
Buen día Guillermo,
Gracias por tu pronta respuesta, tendre en cuenta las vistas y funciones.
Pero por ejemplo, tengo una capa en PostgreSQL/PostGIS, donde tengo campo1,
campo2, campo3 y zonificacion, donde los campo (1,2,3 son compontes que
almacenan calificaciones ambientales , físico, biótico,
Lo mas curioso es que si hago el insert no dentro de una función sino
como una sentencia sql normal, ésto no pasa
No entiendo que pueda ser
El 27/10/10, mas...@gmail.com escribió:
> Hola a todos,
>
> Ya hice eso, tengo la tabla y las funciones con tipo varchar y no char
> y aún así la función me
Hola a todos,
Ya hice eso, tengo la tabla y las funciones con tipo varchar y no char
y aún así la función me sigue dando el mismo error en los datos de
tipo varchar.
Saludos
2010/10/26, Alvaro Herrera :
> Excerpts from mas...@gmail.com's message of mar oct 26 17:41:00 -0300 2010:
>> Hola Jaime
Hola Jhonatan, es simple, el campo que quiere agregar Virginia se puede
calcular en base a otros campos almacenados, entonces no tiene sentido
guardarlo.
Mas aún cuando el cálculo es tan simple que ni siquiera tiene que buscar en
otras filas u otras tablas, con un select lo puede obtener.
Si lo nec
Algo así como EXPLAIN?
EXPLAIN SELECT * FROM USUARIOS
El 27-10-2010, a las 8:57, Gaston Rider escribió:
Buenos Días:
Vengo de SQL-Server, allì habìa una herramienta que la utilizaba
cotidianamente (SQL Server Profiler), la cuál mostraba todas las
querys que procesaba el motor. Tambièn da
pg_top
El 27-10-2010, a las 9:06, Gaston Rider escribió:
No es exactamente lo que busco, recuerden que necesito ver las
querys de "todos" los usuarios en tiempo real o en su defecto
guardarlo en un txt o en una tabla.
el explain solo puedo ejecutarlo con el usuario con el que estoy
logea
No es exactamente lo que busco, recuerden que necesito ver las querys de
"todos" los usuarios en tiempo real o en su defecto guardarlo en un txt o en
una tabla.
el explain solo puedo ejecutarlo con el usuario con el que estoy logeado.
CC: pgsql-es-ayuda@postgresql.org
From: man...@radiohe
2010/10/26 Alvaro Herrera
> Excerpts from Virginia's message of mar oct 26 12:23:47 -0300 2010:
>
> > Ya resolví mi problema, aquí les dejo la solución para quienes puedan
> tener
> > el mismo problema:
>
> Creo que quienes tengan el mismo problema deberían usar una vista para
> evitar almacenar
El mié, 27-10-2010 a las 11:57 +, Gaston Rider escribió:
> Buenos Días:
>
> Vengo de SQL-Server, allì habìa una herramienta que la utilizaba
> cotidianamente (SQL Server Profiler), la cuál mostraba todas las
> querys que procesaba el motor. Tambièn daba la información del tiempo
> que insum
Buenos Días:
Vengo de SQL-Server, allì habìa una herramienta que la utilizaba cotidianamente
(SQL Server Profiler), la cuál mostraba todas las querys que procesaba el
motor. Tambièn daba la información del tiempo que insumió la misma, usuario,
fecha etc. Todo esto en tiempo real
Esto me serví
31 matches
Mail list logo