Re: Alternativa para manejar variables de sesion

Julio Cesar Sánchez González wrote:

> > Hola compañeros listeros aprovechando el hilo que se formo sobre el
> > almacenamiento de imagenes en una base de datos postgres con tipo bytea
> > u oid me surje la duda sobre el rendimiento del ORDBMS pues hablan de
> > 1500 fotos pero que pasaria si ese volumen se procesara diariamente,
> > ¿Que pasaria con la base despues de 1 año? ahora viene otro problema si
> > el tamaño y la resolucion de la imagen no es fijo y tiende a crecer como
> > es el caso de las fotos tomadas con camaras digitales modernas que cada
> > vez son mas grandes por los megapixeles que parece que hoy estan de
> > oferta. En fin que es mejor, almacenar el grafico en la base de datos o
> > mediante un path?
> >
> > Ambos metodos funcionan bien pero cual creen que sea mejor basado en
> > rendimiento del gestor relacional, yo me inclino por el almacenamiento
> > en path, pero ustedes tienen la ultima palabra.
> >
> > Saludos a todos y muchas gracias.
> >
> > Julio Cesar Sanchez G.
>

Tengo mi BD con fotos dentro de la BD. Ya van como 20000 y eso no afecta en
nada mi performance. Almaceno las fotos como base64 y eso me permite q en un
solo bk llevarme todo , es decir, la cosa es super "portable", no se porq
dijeron eso.
Lo q hice es q almaceno las fotos en una tabla con el id de lo que pertence
pero sin relaciones , sola.
Esto me hace q no tengo q cargarla siempre sino solo cuando la necesito.
La forma me ha dado muy buenos resultados

>From: Julio Cesar Sánchez González <knowhow(at)sistemasyconectividad(dot)com(dot)mx>
>Reply-To: knowhow(at)sistemasyconectividad(dot)com(dot)mx
>To: pgsql-es-ayuda(at)postgresql(dot)org
>Subject: [pgsql-es-ayuda] [Fwd: Re: como almacenar una imagen en una tabla
>y no morir por el rendimiento]
>Date: Thu, 26 Oct 2006 01:04:18 -0500
>
>Julio Cesar Sánchez González wrote:
>
>> > Hola compañeros listeros aprovechando el hilo que se formo sobre el >
>>almacenamiento de imagenes en una base de datos postgres con tipo bytea >
>>u oid me surje la duda sobre el rendimiento del ORDBMS pues hablan de >
>>1500 fotos pero que pasaria si ese volumen se procesara diariamente, >
>>¿Que pasaria con la base despues de 1 año? ahora viene otro problema si >
>>el tamaño y la resolucion de la imagen no es fijo y tiende a crecer como >
>>es el caso de las fotos tomadas con camaras digitales modernas que cada >
>>vez son mas grandes por los megapixeles que parece que hoy estan de >
>>oferta. En fin que es mejor, almacenar el grafico en la base de datos o >
>>mediante un path?
>> > > Ambos metodos funcionan bien pero cual creen que sea mejor basado en
>> > rendimiento del gestor relacional, yo me inclino por el almacenamiento
>> > en path, pero ustedes tienen la ultima palabra.
>> > > Saludos a todos y muchas gracias.
>> > > Julio Cesar Sanchez G.
>>

>From: Alvaro Herrera <alvherre(at)commandprompt(dot)com>
>To: Julio Cesar Sánchez González <knowhow(at)sistemasyconectividad(dot)com(dot)mx>
>Subject: Re: como almacenar una imagen en una tabla y no morir por el
>rendimiento
>Date: Wed, 25 Oct 2006 18:01:30 -0300
>Hola,
>
>Por favor reenvia este mensaje a pgsql-es-ayuda(at)postgresql(dot)org, que es la
>direccion de la lista. Sin el -owner, porque esa es la direccion del owner
>(administrador).
>
>Gracias.
>
>
>Julio Cesar Sánchez González wrote:
> > Hola compañeros listeros aprovechando el hilo que se formo sobre el
> > almacenamiento de imagenes en una base de datos postgres con tipo bytea
> > u oid me surje la duda sobre el rendimiento del ORDBMS pues hablan de
> > 1500 fotos pero que pasaria si ese volumen se procesara diariamente,
> > ¿Que pasaria con la base despues de 1 año? ahora viene otro problema si
> > el tamaño y la resolucion de la imagen no es fijo y tiende a crecer como
> > es el caso de las fotos tomadas con camaras digitales modernas que cada
> > vez son mas grandes por los megapixeles que parece que hoy estan de
> > oferta. En fin que es mejor, almacenar el grafico en la base de datos o
> > mediante un path?
> >
> > Ambos metodos funcionan bien pero cual creen que sea mejor basado en
> > rendimiento del gestor relacional, yo me inclino por el almacenamiento
> > en path, pero ustedes tienen la ultima palabra.
> >
> > Saludos a todos y muchas gracias.
> >
> > Julio Cesar Sanchez G.
>

>
>---------------------------(fin del mensaje)---------------------------
>TIP 8: explain analyze es tu amigo

_________________________________________________________________
¿Cuánto vale tu auto? Tips para mantener tu carro. ¡De todo en MSN Latino
Autos! http://latino.msn.com/autos/

El problema de almacenar el path es que las fotos (de querer respaldarlas)
debes respaldar la base (logica) y las fotos (materia prima), si dejas todo
en la base de datos, cuando debas respaldar respalda la logica y la data de
interes (las fotos), te entiendes solo con un agente que es el RDBMS.

Como lo veo yo, es mejor tener todo en la base y no en base64 por que te
sube un % importante el tamaño de la foto.

On 10/26/06, Edwin Quijada <listas_quijada(at)hotmail(dot)com> wrote:
>
>
> Tengo mi BD con fotos dentro de la BD. Ya van como 20000 y eso no afecta
> en
> nada mi performance. Almaceno las fotos como base64 y eso me permite q en
> un
> solo bk llevarme todo , es decir, la cosa es super "portable", no se porq
> dijeron eso.
> Lo q hice es q almaceno las fotos en una tabla con el id de lo que
> pertence
> pero sin relaciones , sola.
> Esto me hace q no tengo q cargarla siempre sino solo cuando la necesito.
> La forma me ha dado muy buenos resultados
>
>
>
> >From: Julio Cesar Sánchez González <knowhow(at)sistemasyconectividad(dot)com(dot)mx>
> >Reply-To: knowhow(at)sistemasyconectividad(dot)com(dot)mx
> >To: pgsql-es-ayuda(at)postgresql(dot)org
> >Subject: [pgsql-es-ayuda] [Fwd: Re: como almacenar una imagen en una
> tabla
> >y no morir por el rendimiento]
> >Date: Thu, 26 Oct 2006 01:04:18 -0500
> >
> >Julio Cesar Sánchez González wrote:
> >
> >> > Hola compañeros listeros aprovechando el hilo que se formo sobre el >
> >>almacenamiento de imagenes en una base de datos postgres con tipo bytea
> >
> >>u oid me surje la duda sobre el rendimiento del ORDBMS pues hablan de >
> >>1500 fotos pero que pasaria si ese volumen se procesara diariamente, >
> >>¿Que pasaria con la base despues de 1 año? ahora viene otro problema si
> >
> >>el tamaño y la resolucion de la imagen no es fijo y tiende a crecer como
> >
> >>es el caso de las fotos tomadas con camaras digitales modernas que cada
> >
> >>vez son mas grandes por los megapixeles que parece que hoy estan de >
> >>oferta. En fin que es mejor, almacenar el grafico en la base de datos o
> >
> >>mediante un path?
> >> > > Ambos metodos funcionan bien pero cual creen que sea mejor basado
> en
> >> > rendimiento del gestor relacional, yo me inclino por el
> almacenamiento
> >> > en path, pero ustedes tienen la ultima palabra.
> >> > > Saludos a todos y muchas gracias.
> >> > > Julio Cesar Sanchez G.
> >>
>
>
>
> >From: Alvaro Herrera <alvherre(at)commandprompt(dot)com>
> >To: Julio Cesar Sánchez González <knowhow(at)sistemasyconectividad(dot)com(dot)mx>
> >Subject: Re: como almacenar una imagen en una tabla y no morir por el
> >rendimiento
> >Date: Wed, 25 Oct 2006 18:01:30 -0300
> >Hola,
> >
> >Por favor reenvia este mensaje a pgsql-es-ayuda(at)postgresql(dot)org, que es la
> >direccion de la lista. Sin el -owner, porque esa es la direccion del
> owner
> >(administrador).
> >
> >Gracias.
> >
> >
> >Julio Cesar Sánchez González wrote:
> > > Hola compañeros listeros aprovechando el hilo que se formo sobre el
> > > almacenamiento de imagenes en una base de datos postgres con tipo
> bytea
> > > u oid me surje la duda sobre el rendimiento del ORDBMS pues hablan de
> > > 1500 fotos pero que pasaria si ese volumen se procesara diariamente,
> > > ¿Que pasaria con la base despues de 1 año? ahora viene otro problema
> si
> > > el tamaño y la resolucion de la imagen no es fijo y tiende a crecer
> como
> > > es el caso de las fotos tomadas con camaras digitales modernas que
> cada
> > > vez son mas grandes por los megapixeles que parece que hoy estan de
> > > oferta. En fin que es mejor, almacenar el grafico en la base de datos
> o
> > > mediante un path?
> > >
> > > Ambos metodos funcionan bien pero cual creen que sea mejor basado en
> > > rendimiento del gestor relacional, yo me inclino por el almacenamiento
> > > en path, pero ustedes tienen la ultima palabra.
> > >
> > > Saludos a todos y muchas gracias.
> > >
> > > Julio Cesar Sanchez G.
> >
>
>
>
>
>
>
> >
> >---------------------------(fin del mensaje)---------------------------
> >TIP 8: explain analyze es tu amigo
>
> _________________________________________________________________
> ¿Cuánto vale tu auto? Tips para mantener tu carro. ¡De todo en MSN Latino
> Autos! http://latino.msn.com/autos/
>
>
> ---------------------------(fin del mensaje)---------------------------
> TIP 9: el optimizador ignorará el uso de recorridos de índice si los
> tipos de datos de las columnas no coinciden
>

--
Saludos,
Horacio Miranda Aguilera.
RedHat Certified Engineer
(56 99) - 8841727

>From: "Horacio Miranda" <hmiranda(at)gmail(dot)com>
>To: "Edwin Quijada" <listas_quijada(at)hotmail(dot)com>
>CC: knowhow(at)sistemasyconectividad(dot)com(dot)mx, pgsql-es-ayuda(at)postgresql(dot)org
>Subject: Re: [pgsql-es-ayuda] [Fwd: Re: como almacenar una imagen en una
>tabla y no morir
>Date: Thu, 26 Oct 2006 17:25:52 -0300
>
>El problema de almacenar el path es que las fotos (de querer respaldarlas)
>debes respaldar la base (logica) y las fotos (materia prima), si dejas todo
>en la base de datos, cuando debas respaldar respalda la logica y la data de
>interes (las fotos), te entiendes solo con un agente que es el RDBMS.
>
>Como lo veo yo, es mejor tener todo en la base y no en base64 por que te
>sube un % importante el tamaño de la foto.
>
>
Nop. No sube.

>On 10/26/06, Edwin Quijada <listas_quijada(at)hotmail(dot)com> wrote:
>>
>>
>>Tengo mi BD con fotos dentro de la BD. Ya van como 20000 y eso no afecta
>>en
>>nada mi performance. Almaceno las fotos como base64 y eso me permite q en
>>un
>>solo bk llevarme todo , es decir, la cosa es super "portable", no se porq
>>dijeron eso.
>>Lo q hice es q almaceno las fotos en una tabla con el id de lo que
>>pertence
>>pero sin relaciones , sola.
>>Esto me hace q no tengo q cargarla siempre sino solo cuando la necesito.
>>La forma me ha dado muy buenos resultados
>>
>>
>>
>> >From: Julio Cesar Sánchez González
>><knowhow(at)sistemasyconectividad(dot)com(dot)mx>
>> >Reply-To: knowhow(at)sistemasyconectividad(dot)com(dot)mx
>> >To: pgsql-es-ayuda(at)postgresql(dot)org
>> >Subject: [pgsql-es-ayuda] [Fwd: Re: como almacenar una imagen en una
>>tabla
>> >y no morir por el rendimiento]
>> >Date: Thu, 26 Oct 2006 01:04:18 -0500
>> >
>> >Julio Cesar Sánchez González wrote:
>> >
>> >> > Hola compañeros listeros aprovechando el hilo que se formo sobre el
>> >
>> >>almacenamiento de imagenes en una base de datos postgres con tipo bytea
>> >
>> >>u oid me surje la duda sobre el rendimiento del ORDBMS pues hablan de >
>> >>1500 fotos pero que pasaria si ese volumen se procesara diariamente, >
>> >>¿Que pasaria con la base despues de 1 año? ahora viene otro problema si
>> >
>> >>el tamaño y la resolucion de la imagen no es fijo y tiende a crecer
>>como
>> >
>> >>es el caso de las fotos tomadas con camaras digitales modernas que cada
>> >
>> >>vez son mas grandes por los megapixeles que parece que hoy estan de >
>> >>oferta. En fin que es mejor, almacenar el grafico en la base de datos o
>> >
>> >>mediante un path?
>> >> > > Ambos metodos funcionan bien pero cual creen que sea mejor basado
>>en
>> >> > rendimiento del gestor relacional, yo me inclino por el
>>almacenamiento
>> >> > en path, pero ustedes tienen la ultima palabra.
>> >> > > Saludos a todos y muchas gracias.
>> >> > > Julio Cesar Sanchez G.
>> >>
>>
>>
>>
>> >From: Alvaro Herrera <alvherre(at)commandprompt(dot)com>
>> >To: Julio Cesar Sánchez González <knowhow(at)sistemasyconectividad(dot)com(dot)mx>
>> >Subject: Re: como almacenar una imagen en una tabla y no morir por el
>> >rendimiento
>> >Date: Wed, 25 Oct 2006 18:01:30 -0300
>> >Hola,
>> >
>> >Por favor reenvia este mensaje a pgsql-es-ayuda(at)postgresql(dot)org, que es
>>la
>> >direccion de la lista. Sin el -owner, porque esa es la direccion del
>>owner
>> >(administrador).
>> >
>> >Gracias.
>> >
>> >
>> >Julio Cesar Sánchez González wrote:
>> > > Hola compañeros listeros aprovechando el hilo que se formo sobre el
>> > > almacenamiento de imagenes en una base de datos postgres con tipo
>>bytea
>> > > u oid me surje la duda sobre el rendimiento del ORDBMS pues hablan de
>> > > 1500 fotos pero que pasaria si ese volumen se procesara diariamente,
>> > > ¿Que pasaria con la base despues de 1 año? ahora viene otro problema
>>si
>> > > el tamaño y la resolucion de la imagen no es fijo y tiende a crecer
>>como
>> > > es el caso de las fotos tomadas con camaras digitales modernas que
>>cada
>> > > vez son mas grandes por los megapixeles que parece que hoy estan de
>> > > oferta. En fin que es mejor, almacenar el grafico en la base de datos
>>o
>> > > mediante un path?
>> > >
>> > > Ambos metodos funcionan bien pero cual creen que sea mejor basado en
>> > > rendimiento del gestor relacional, yo me inclino por el
>>almacenamiento
>> > > en path, pero ustedes tienen la ultima palabra.
>> > >
>> > > Saludos a todos y muchas gracias.
>> > >
>> > > Julio Cesar Sanchez G.
>> >
>>
>>
>>
>>
>>
>>
>> >
>> >---------------------------(fin del mensaje)---------------------------
>> >TIP 8: explain analyze es tu amigo
>>
>>_________________________________________________________________
>>¿Cuánto vale tu auto? Tips para mantener tu carro. ¡De todo en MSN Latino
>>Autos! http://latino.msn.com/autos/
>>
>>
>>---------------------------(fin del mensaje)---------------------------
>>TIP 9: el optimizador ignorará el uso de recorridos de índice si los
>> tipos de datos de las columnas no coinciden
>>
>
>
>
>--
>Saludos,
>Horacio Miranda Aguilera.
>RedHat Certified Engineer
>(56 99) - 8841727

_________________________________________________________________
Visita MSN Latino Entretenimiento: ¡música, cine, chismes, TV y más...!
http://latino.msn.com/entretenimiento/

PC Serv. Archivos PC Serv.Base de Datos
IP 192.168.1.x IP 192.168.1.y

PC Serv. Web
IP 192.168.1.z
IP 200.110.30.26

Como podrás ver, las fotografías se encuentran protegidas en un servidor
interno de la empresa, la única PC que da la cara al exterior es el
Servidor web, es decir la pagina que podría mostrarte las fotografías. Si
observas el Motor de Base de Datos tampoco debería estar expuesto al
exterior, aunque no forwarees el puerto respectivo al motor con el IP de
la PC que lo carga en el ruteador de la CIA.

Considerando la ligereza que debe tener el servidor de base de datos en su
trabajo de servirnos con información que requiramos, no te recomiendo
tener las fotografías en la base de datos, solo crea una tabla con los IDs
respectivos por fotografía y a cada fotografía renómbrala al ID de la
tabla.

No cargues demasiado al motor de base de datos, si en verdad no es
necesario. a veces las cosas faciles son las mas caras de pagar.

Saludos.

"Horacio Miranda" <hmiranda(at)gmail(dot)com>
Enviado por: pgsql-es-ayuda-owner(at)postgresql(dot)org
26/10/2006 03:25 p.m.

Para
"Edwin Quijada" <listas_quijada(at)hotmail(dot)com>
cc
knowhow(at)sistemasyconectividad(dot)com(dot)mx, pgsql-es-ayuda(at)postgresql(dot)org
Asunto
Re: [pgsql-es-ayuda] [Fwd: Re: como almacenar una imagen en una tabla y no
morir

El problema de almacenar el path es que las fotos (de querer respaldarlas)
debes respaldar la base (logica) y las fotos (materia prima), si dejas
todo en la base de datos, cuando debas respaldar respalda la logica y la
data de interes (las fotos), te entiendes solo con un agente que es el
RDBMS.

Como lo veo yo, es mejor tener todo en la base y no en base64 por que te
sube un % importante el tamaño de la foto.

On 10/26/06, Edwin Quijada <listas_quijada(at)hotmail(dot)com> wrote:

Tengo mi BD con fotos dentro de la BD. Ya van como 20000 y eso no afecta
en
nada mi performance. Almaceno las fotos como base64 y eso me permite q en
un
solo bk llevarme todo , es decir, la cosa es super "portable", no se porq
dijeron eso.
Lo q hice es q almaceno las fotos en una tabla con el id de lo que
pertence
pero sin relaciones , sola.
Esto me hace q no tengo q cargarla siempre sino solo cuando la necesito.
La forma me ha dado muy buenos resultados

>From: Julio Cesar Sánchez González <knowhow(at)sistemasyconectividad(dot)com(dot)mx>
>Reply-To: knowhow(at)sistemasyconectividad(dot)com(dot)mx
>To: pgsql-es-ayuda(at)postgresql(dot)org
>Subject: [pgsql-es-ayuda] [Fwd: Re: como almacenar una imagen en una
tabla
>y no morir por el rendimiento]
>Date: Thu, 26 Oct 2006 01:04:18 -0500
>
>Julio Cesar Sánchez González wrote:
>
>> > Hola compañeros listeros aprovechando el hilo que se formo sobre el >
>>almacenamiento de imagenes en una base de datos postgres con tipo bytea
>
>>u oid me surje la duda sobre el rendimiento del ORDBMS pues hablan de >
>>1500 fotos pero que pasaria si ese volumen se procesara diariamente, >
>>¿Que pasaria con la base despues de 1 año? ahora viene otro problema si
>
>>el tamaño y la resolucion de la imagen no es fijo y tiende a crecer como
>
>>es el caso de las fotos tomadas con camaras digitales modernas que cada
>
>>vez son mas grandes por los megapixeles que parece que hoy estan de >
>>oferta. En fin que es mejor, almacenar el grafico en la base de datos o
>
>>mediante un path?
>> > > Ambos metodos funcionan bien pero cual creen que sea mejor basado
en
>> > rendimiento del gestor relacional, yo me inclino por el
almacenamiento
>> > en path, pero ustedes tienen la ultima palabra.
>> > > Saludos a todos y muchas gracias.
>> > > Julio Cesar Sanchez G.
>>

>From: Alvaro Herrera < alvherre(at)commandprompt(dot)com>
>To: Julio Cesar Sánchez González <knowhow(at)sistemasyconectividad(dot)com(dot)mx>
>Subject: Re: como almacenar una imagen en una tabla y no morir por el
>rendimiento
>Date: Wed, 25 Oct 2006 18:01:30 -0300
>Hola,
>
>Por favor reenvia este mensaje a pgsql-es-ayuda(at)postgresql(dot)org, que es la
>direccion de la lista. Sin el -owner, porque esa es la direccion del
owner
>(administrador).
>
>Gracias.
>
>
>Julio Cesar Sánchez González wrote:
> > Hola compañeros listeros aprovechando el hilo que se formo sobre el
> > almacenamiento de imagenes en una base de datos postgres con tipo
bytea
> > u oid me surje la duda sobre el rendimiento del ORDBMS pues hablan de
> > 1500 fotos pero que pasaria si ese volumen se procesara diariamente,
> > ¿Que pasaria con la base despues de 1 año? ahora viene otro problema
si
> > el tamaño y la resolucion de la imagen no es fijo y tiende a crecer
como
> > es el caso de las fotos tomadas con camaras digitales modernas que
cada
> > vez son mas grandes por los megapixeles que parece que hoy estan de
> > oferta. En fin que es mejor, almacenar el grafico en la base de datos
o
> > mediante un path?
> >
> > Ambos metodos funcionan bien pero cual creen que sea mejor basado en
> > rendimiento del gestor relacional, yo me inclino por el almacenamiento
> > en path, pero ustedes tienen la ultima palabra.
> >
> > Saludos a todos y muchas gracias.
> >
> > Julio Cesar Sanchez G.
>

>
>---------------------------(fin del mensaje)---------------------------
>TIP 8: explain analyze es tu amigo

_________________________________________________________________
¿Cuánto vale tu auto? Tips para mantener tu carro. ¡De todo en MSN Latino
Autos! http://latino.msn.com/autos/

---------------------------(fin del mensaje)---------------------------
TIP 9: el optimizador ignorará el uso de recorridos de índice si los
tipos de datos de las columnas no coinciden

--
Saludos,
Horacio Miranda Aguilera.
RedHat Certified Engineer
(56 99) - 8841727

Edwin Quijada escribió:

> >Como lo veo yo, es mejor tener todo en la base y no en base64 por que te
> >sube un % importante el tamaño de la foto.
> >
> Nop. No sube.

Es imposible que no suba. El formato base64 _esta definido_ de forma
que agrega un 35% de tamaño a los archivos.

--
Alvaro Herrera http://www.CommandPrompt.com/
The PostgreSQL Company - Command Prompt, Inc.

Cordial Saludo Listeros.

Según he leido postgresql aún no implementa variables de sesión ... alguien
conoce alguna alternativa?

Lo que se me ocurre es que cada que se inicie una sesion, se grabe a una
tabla el id de la sesion junto con el valor que quiero almacenar. Cuando
requiero este valor lo consulto en esa tabla por el id de la sesion activa.
Cuando se cierre la sesion borro el registro correspondiente.

Para esta implementación tengo dos dudas.
1. Cómo obtengo el id de la sesion/conexión activa?
2. Cómo pueedo crear una función que se ejecute antes de que se cierre una
sesión/conexión, algo así como un trigger pero que se ejecute cuando se
cierra una sesion/conexion.

Gracias.

Atentamente,

RAUL DUQUE
Bogotá, Colombia

Cordial Saludo Listeros.

Alguien sabe como implementar cubos (OLAP) en postgresql?

Atentamente,

RAUL DUQUE
Bogotá, COlombia

Bueno, si no me equivoco estás hablando de DataWarehouse
cierto? Bueno, si es así trata de probar con Bizgres:

www.bizgres.org

No he tenido la oportunidad de probarlo, así que si logras hacer
algo con él me gustaría que nos contaras que tal te fue.

Saludos...

El día 27/10/06, Raúl Andrés Duque <raulandresduque(at)hotmail(dot)com> escribió:
>
> Cordial Saludo Listeros.
>
> Alguien sabe como implementar cubos (OLAP) en postgresql?
>
> Atentamente,
>
> RAUL DUQUE
> Bogotá, COlombia
>
>
> ---------------------------(fin del mensaje)---------------------------
> TIP 2: puedes desuscribirte de todas las listas simultáneamente
> (envíe "unregister TuDirecciónDeCorreo" a majordomo(at)postgresql(dot)org)
>

--
Luis D. García M.
Telf: 0414-3482018

- FACYT - UC -
- Computación -

El vie, 27-10-2006 a las 03:46 -0500, Raúl Andrés Duque escribió:
> Cordial Saludo Listeros.
>
> Según he leido postgresql aún no implementa variables de sesión ... alguien
> conoce alguna alternativa?
>
> Lo que se me ocurre es que cada que se inicie una sesion, se grabe a una
> tabla el id de la sesion junto con el valor que quiero almacenar. Cuando
> requiero este valor lo consulto en esa tabla por el id de la sesion activa.
> Cuando se cierre la sesion borro el registro correspondiente.
>
> Para esta implementación tengo dos dudas.
> 1. Cómo obtengo el id de la sesion/conexión activa?

SELECT pg_backend_pid();

> 2. Cómo pueedo crear una función que se ejecute antes de que se cierre una
> sesión/conexión, algo así como un trigger pero que se ejecute cuando se
> cierra una sesion/conexion.

Creo que no se puede, pero no estoy seguro!

Yo hago lo siguiente.

Al iniciar la sesión creo una tabla temporal la cual es eliminada
automáticamente al terminar la sesión. Además no requieres del
identificador de sesión ya que ésta es solo visible para el
usuario/sesión actual.

Mi tabla temporal es algo como esto:

CREATE TEMP TABLE of_param_sesion
(IdParam TEXT,
IdValor TEXT);

>
> Gracias.
--
Jamcha

Perdón pero hasta ahora llego a la lista y me parece interesante el tema de
almacenar fotos en la DB.

cómo se dijo que debía hacerse?
Se convierte la foto a base64 y se almacena como varchar?
como hago un insert? el base64 ente '' cómo si fuera una cadena?

Gracias.

Atentamente,

RAUL DUQUE
Bogotá, Colombia
----- Original Message -----
From: "Edwin Quijada" <listas_quijada(at)hotmail(dot)com>
To: <hmiranda(at)gmail(dot)com>
Cc: <pgsql-es-ayuda(at)postgresql(dot)org>
Sent: Thursday, October 26, 2006 3:29 PM
Subject: Re: [pgsql-es-ayuda] [Fwd: Re: como almacenar una imagen en una
tabla y no morir

>
>
>
>
>
>>From: "Horacio Miranda" <hmiranda(at)gmail(dot)com>
>>To: "Edwin Quijada" <listas_quijada(at)hotmail(dot)com>
>>CC: knowhow(at)sistemasyconectividad(dot)com(dot)mx, pgsql-es-ayuda(at)postgresql(dot)org
>>Subject: Re: [pgsql-es-ayuda] [Fwd: Re: como almacenar una imagen en una
>>tabla y no morir
>>Date: Thu, 26 Oct 2006 17:25:52 -0300
>>
>>El problema de almacenar el path es que las fotos (de querer respaldarlas)
>>debes respaldar la base (logica) y las fotos (materia prima), si dejas
>>todo
>>en la base de datos, cuando debas respaldar respalda la logica y la data
>>de
>>interes (las fotos), te entiendes solo con un agente que es el RDBMS.
>>
>>Como lo veo yo, es mejor tener todo en la base y no en base64 por que te
>>sube un % importante el tamaño de la foto.
>>
>>
> Nop. No sube.
>
>
>>On 10/26/06, Edwin Quijada <listas_quijada(at)hotmail(dot)com> wrote:
>>>
>>>
>>>Tengo mi BD con fotos dentro de la BD. Ya van como 20000 y eso no afecta
>>>en
>>>nada mi performance. Almaceno las fotos como base64 y eso me permite q en
>>>un
>>>solo bk llevarme todo , es decir, la cosa es super "portable", no se porq
>>>dijeron eso.
>>>Lo q hice es q almaceno las fotos en una tabla con el id de lo que
>>>pertence
>>>pero sin relaciones , sola.
>>>Esto me hace q no tengo q cargarla siempre sino solo cuando la necesito.
>>>La forma me ha dado muy buenos resultados
>>>
>>>
>>>
>>> >From: Julio Cesar Sánchez González
>>><knowhow(at)sistemasyconectividad(dot)com(dot)mx>
>>> >Reply-To: knowhow(at)sistemasyconectividad(dot)com(dot)mx
>>> >To: pgsql-es-ayuda(at)postgresql(dot)org
>>> >Subject: [pgsql-es-ayuda] [Fwd: Re: como almacenar una imagen en una
>>>tabla
>>> >y no morir por el rendimiento]
>>> >Date: Thu, 26 Oct 2006 01:04:18 -0500
>>> >
>>> >Julio Cesar Sánchez González wrote:
>>> >
>>> >> > Hola compañeros listeros aprovechando el hilo que se formo sobre el
>>> >
>>> >>almacenamiento de imagenes en una base de datos postgres con tipo
>>> >>bytea
>>> >
>>> >>u oid me surje la duda sobre el rendimiento del ORDBMS pues hablan de
>>> >> >
>>> >>1500 fotos pero que pasaria si ese volumen se procesara diariamente, >
>>> >>¿Que pasaria con la base despues de 1 año? ahora viene otro problema
>>> >>si
>>> >
>>> >>el tamaño y la resolucion de la imagen no es fijo y tiende a crecer
>>>como
>>> >
>>> >>es el caso de las fotos tomadas con camaras digitales modernas que
>>> >>cada
>>> >
>>> >>vez son mas grandes por los megapixeles que parece que hoy estan de >
>>> >>oferta. En fin que es mejor, almacenar el grafico en la base de datos
>>> >>o
>>> >
>>> >>mediante un path?
>>> >> > > Ambos metodos funcionan bien pero cual creen que sea mejor basado
>>>en
>>> >> > rendimiento del gestor relacional, yo me inclino por el
>>>almacenamiento
>>> >> > en path, pero ustedes tienen la ultima palabra.
>>> >> > > Saludos a todos y muchas gracias.
>>> >> > > Julio Cesar Sanchez G.
>>> >>
>>>
>>>
>>>
>>> >From: Alvaro Herrera <alvherre(at)commandprompt(dot)com>
>>> >To: Julio Cesar Sánchez González <knowhow(at)sistemasyconectividad(dot)com(dot)mx>
>>> >Subject: Re: como almacenar una imagen en una tabla y no morir por el
>>> >rendimiento
>>> >Date: Wed, 25 Oct 2006 18:01:30 -0300
>>> >Hola,
>>> >
>>> >Por favor reenvia este mensaje a pgsql-es-ayuda(at)postgresql(dot)org, que es
>>>la
>>> >direccion de la lista. Sin el -owner, porque esa es la direccion del
>>>owner
>>> >(administrador).
>>> >
>>> >Gracias.
>>> >
>>> >
>>> >Julio Cesar Sánchez González wrote:
>>> > > Hola compañeros listeros aprovechando el hilo que se formo sobre el
>>> > > almacenamiento de imagenes en una base de datos postgres con tipo
>>>bytea
>>> > > u oid me surje la duda sobre el rendimiento del ORDBMS pues hablan
>>> > > de
>>> > > 1500 fotos pero que pasaria si ese volumen se procesara diariamente,
>>> > > ¿Que pasaria con la base despues de 1 año? ahora viene otro problema
>>>si
>>> > > el tamaño y la resolucion de la imagen no es fijo y tiende a crecer
>>>como
>>> > > es el caso de las fotos tomadas con camaras digitales modernas que
>>>cada
>>> > > vez son mas grandes por los megapixeles que parece que hoy estan de
>>> > > oferta. En fin que es mejor, almacenar el grafico en la base de
>>> > > datos
>>>o
>>> > > mediante un path?
>>> > >
>>> > > Ambos metodos funcionan bien pero cual creen que sea mejor basado en
>>> > > rendimiento del gestor relacional, yo me inclino por el
>>>almacenamiento
>>> > > en path, pero ustedes tienen la ultima palabra.
>>> > >
>>> > > Saludos a todos y muchas gracias.
>>> > >
>>> > > Julio Cesar Sanchez G.
>>> >
>>>
>>>
>>>
>>>
>>>
>>>
>>> >
>>> >---------------------------(fin del mensaje)---------------------------
>>> >TIP 8: explain analyze es tu amigo
>>>
>>>_________________________________________________________________
>>>¿Cuánto vale tu auto? Tips para mantener tu carro. ¡De todo en MSN Latino
>>>Autos! http://latino.msn.com/autos/
>>>
>>>
>>>---------------------------(fin del mensaje)---------------------------
>>>TIP 9: el optimizador ignorará el uso de recorridos de índice si los
>>> tipos de datos de las columnas no coinciden
>>>
>>
>>
>>
>>--
>>Saludos,
>>Horacio Miranda Aguilera.
>>RedHat Certified Engineer
>>(56 99) - 8841727
>
> _________________________________________________________________
> Visita MSN Latino Entretenimiento: ¡música, cine, chismes, TV y más...!
> http://latino.msn.com/entretenimiento/
>
>
> ---------------------------(fin del mensaje)---------------------------
> TIP 4: No hagas 'kill -9' a postmaster
>

Para la creación de cubos prueba con mondrian una herramienta de software
libre, yo la he probado y funciona bien, todo en web.

http://mondrian.pentaho.org/index.php

Además ahora mondrian se ha unido con pentaho, una herramienta de BI.

> Cordial Saludo Listeros.
>
> Alguien sabe como implementar cubos (OLAP) en postgresql?
>
> Atentamente,
>
> RAUL DUQUE
> Bogotá, COlombia
>
>
> ---------------------------(fin del mensaje)---------------------------
> TIP 2: puedes desuscribirte de todas las listas simultáneamente
> (envíe "unregister TuDirecciónDeCorreo" a majordomo(at)postgresql(dot)org)
>

Raul Andres Duque escribió:
> Perdón pero hasta ahora llego a la lista y me parece interesante el tema de
> almacenar fotos en la DB.
>
> cómo se dijo que debía hacerse?

Que lenguaje quieres usar?

> Se convierte la foto a base64 y se almacena como varchar?

No, se almacena como bytea.

--
Alvaro Herrera http://www.CommandPrompt.com/
PostgreSQL Replication, Consulting, Custom Development, 24x7 support

Muy buena alternativa y sencilla ... muchas gracias Jaime !!!

Atentamente,

RAUL DUQUE
Bogotá, Colombia

----- Original Message -----
From: "Jaime Charles" <jamcha(at)sinc(dot)com(dot)mx>
To: <pgsql-es-ayuda(at)postgresql(dot)org>
Sent: Friday, October 27, 2006 10:01 AM
Subject: Re: [pgsql-es-ayuda] Alternativa para manejar variables de sesion

> El vie, 27-10-2006 a las 03:46 -0500, Raúl Andrés Duque escribió:
>> Cordial Saludo Listeros.
>>
>> Según he leido postgresql aún no implementa variables de sesión ...
>> alguien
>> conoce alguna alternativa?
>>
>> Lo que se me ocurre es que cada que se inicie una sesion, se grabe a una
>> tabla el id de la sesion junto con el valor que quiero almacenar. Cuando
>> requiero este valor lo consulto en esa tabla por el id de la sesion
>> activa.
>> Cuando se cierre la sesion borro el registro correspondiente.
>>
>> Para esta implementación tengo dos dudas.
>> 1. Cómo obtengo el id de la sesion/conexión activa?
>
> SELECT pg_backend_pid();
>
>> 2. Cómo pueedo crear una función que se ejecute antes de que se cierre
>> una
>> sesión/conexión, algo así como un trigger pero que se ejecute cuando se
>> cierra una sesion/conexion.
>
> Creo que no se puede, pero no estoy seguro!
>
> Yo hago lo siguiente.
>
> Al iniciar la sesión creo una tabla temporal la cual es eliminada
> automáticamente al terminar la sesión. Además no requieres del
> identificador de sesión ya que ésta es solo visible para el
> usuario/sesión actual.
>
> Mi tabla temporal es algo como esto:
>
> CREATE TEMP TABLE of_param_sesion
> (IdParam TEXT,
> IdValor TEXT);
>
>
>
>>
>> Gracias.
> --
> Jamcha
>
>
> ---------------------------(fin del mensaje)---------------------------
> TIP 7: no olvides aumentar la configuracin del "free space map"
>

> Perdón pero hasta ahora llego a la lista y me parece interesante el tema
> de
> almacenar fotos en la DB.
>
> cómo se dijo que debía hacerse?

depende del lenguaje que quieras usar ..

> Se convierte la foto a base64 y se almacena como varchar?
es una opcion pero no la mas optima

usas campos bytea

> como hago un insert? el base64 ente '' cómo si fuera una cadena?
si te vas por base64 si pero lo "mas mejor" es usar campos ByteA

leonel

La pregunta es para que querria Postgres usar variables de session??
No entiendo?
Puedes explicarte mejor en lo que deseas hacer o para que?

*-------------------------------------------------------*
*-Edwin Quijada
*-Developer DataBase
*-JQ Microsistemas
*-809-747-2787
* " Si deseas lograr cosas excepcionales debes de hacer cosas fuera de lo
comun"
*-------------------------------------------------------*

>From: Raúl Andrés Duque <raulandresduque(at)hotmail(dot)com>
>To: <pgsql-es-ayuda(at)postgresql(dot)org>
>Subject: [pgsql-es-ayuda] Alternativa para manejar variables de sesion
>Date: Fri, 27 Oct 2006 03:46:46 -0500
>
>Cordial Saludo Listeros.
>
>Según he leido postgresql aún no implementa variables de sesión ... alguien
>conoce alguna alternativa?
>
>Lo que se me ocurre es que cada que se inicie una sesion, se grabe a una
>tabla el id de la sesion junto con el valor que quiero almacenar. Cuando
>requiero este valor lo consulto en esa tabla por el id de la sesion activa.
>Cuando se cierre la sesion borro el registro correspondiente.
>
>Para esta implementación tengo dos dudas.
>1. Cómo obtengo el id de la sesion/conexión activa?
>2. Cómo pueedo crear una función que se ejecute antes de que se cierre una
>sesión/conexión, algo así como un trigger pero que se ejecute cuando se
>cierra una sesion/conexion.
>
>Gracias.
>
>Atentamente,
>
>RAUL DUQUE
>Bogotá, Colombia
>
>
>---------------------------(fin del mensaje)---------------------------
>TIP 1: para suscribirte y desuscribirte, visita
>http://archives.postgresql.org/pgsql-es-ayuda

_________________________________________________________________
De todo para la Mujer Latina http://latino.msn.com/mujer/

Que tal Edwin ... esto de las variables de sesion no es nada que me haya
inventado ... algunos motores las implementan.

Un ejemplo sencillo de su utilización:
Se tiene una aplicación donde TODOS los usuarios acceden a la DB con un
usuario genérico y es la aplicación la que controla la parte de permisos
(usuario en la aplicación) ... si quisieras montar un trigger para por
ejemplo auditar cambios de estado, cómo podrías saber que usuario realizó la
operación? Una alternativa es al iniciar la sesión se define una variable
con el id del usuario ... cuestion que cualquier trigger puede hacer uso de
esa variable.

Atentamente,

RAUL DUQUE
Bogotá, Colombia

----- Original Message -----
From: "Edwin Quijada" <listas_quijada(at)hotmail(dot)com>
To: <raulandresduque(at)hotmail(dot)com>
Cc: <pgsql-es-ayuda(at)postgresql(dot)org>
Sent: Saturday, October 28, 2006 9:00 AM
Subject: RE: [pgsql-es-ayuda] Alternativa para manejar variables de sesion

> La pregunta es para que querria Postgres usar variables de session??
> No entiendo?
> Puedes explicarte mejor en lo que deseas hacer o para que?
>
>
> *-------------------------------------------------------*
> *-Edwin Quijada
> *-Developer DataBase
> *-JQ Microsistemas
> *-809-747-2787
> * " Si deseas lograr cosas excepcionales debes de hacer cosas fuera de lo
> comun"
> *-------------------------------------------------------*
>
>
>
>
>>From: Raúl Andrés Duque <raulandresduque(at)hotmail(dot)com>
>>To: <pgsql-es-ayuda(at)postgresql(dot)org>
>>Subject: [pgsql-es-ayuda] Alternativa para manejar variables de sesion
>>Date: Fri, 27 Oct 2006 03:46:46 -0500
>>
>>Cordial Saludo Listeros.
>>
>>Según he leido postgresql aún no implementa variables de sesión ...
>>alguien conoce alguna alternativa?
>>
>>Lo que se me ocurre es que cada que se inicie una sesion, se grabe a una
>>tabla el id de la sesion junto con el valor que quiero almacenar. Cuando
>>requiero este valor lo consulto en esa tabla por el id de la sesion
>>activa. Cuando se cierre la sesion borro el registro correspondiente.
>>
>>Para esta implementación tengo dos dudas.
>>1. Cómo obtengo el id de la sesion/conexión activa?
>>2. Cómo pueedo crear una función que se ejecute antes de que se cierre una
>>sesión/conexión, algo así como un trigger pero que se ejecute cuando se
>>cierra una sesion/conexion.
>>
>>Gracias.
>>
>>Atentamente,
>>
>>RAUL DUQUE
>>Bogotá, Colombia
>>
>>
>>---------------------------(fin del mensaje)---------------------------
>>TIP 1: para suscribirte y desuscribirte, visita
>>http://archives.postgresql.org/pgsql-es-ayuda
>
> _________________________________________________________________
> De todo para la Mujer Latina http://latino.msn.com/mujer/
>
>

Un caso mas concreto es en las aplicaciones Web donde el servidor Web por lo
general se conect a la base de datos con un solo usuario ( usuario de base
de datos ) y claro los usuarios se distinguen unos de otros con usuarios de
aplicación. En este sentido si es necesario usar variables de sesion.

Es mas ... algunos sistemas cliente servidor, tambien usan conecciones de un
solo usuario ( proxy user ) a la base de datos y se diferencian solamente
por usuarios de aplicación.

Saludos,

Javier.

----- Original Message -----
From: "Raúl Andrés Duque" <raulandresduque(at)hotmail(dot)com>
To: <pgsql-es-ayuda(at)postgresql(dot)org>
Sent: Saturday, October 28, 2006 2:40 PM
Subject: Re: [pgsql-es-ayuda] Alternativa para manejar variables de sesion

> Que tal Edwin ... esto de las variables de sesion no es nada que me haya
> inventado ... algunos motores las implementan.
>
> Un ejemplo sencillo de su utilización:
> Se tiene una aplicación donde TODOS los usuarios acceden a la DB con un
> usuario genérico y es la aplicación la que controla la parte de permisos
> (usuario en la aplicación) ... si quisieras montar un trigger para por
> ejemplo auditar cambios de estado, cómo podrías saber que usuario realizó
> la operación? Una alternativa es al iniciar la sesión se define una
> variable con el id del usuario ... cuestion que cualquier trigger puede
> hacer uso de esa variable.
>
> Atentamente,
>
> RAUL DUQUE
> Bogotá, Colombia
>
> ----- Original Message -----
> From: "Edwin Quijada" <listas_quijada(at)hotmail(dot)com>
> To: <raulandresduque(at)hotmail(dot)com>
> Cc: <pgsql-es-ayuda(at)postgresql(dot)org>
> Sent: Saturday, October 28, 2006 9:00 AM
> Subject: RE: [pgsql-es-ayuda] Alternativa para manejar variables de sesion
>
>
>> La pregunta es para que querria Postgres usar variables de session??
>> No entiendo?
>> Puedes explicarte mejor en lo que deseas hacer o para que?
>>
>>
>> *-------------------------------------------------------*
>> *-Edwin Quijada
>> *-Developer DataBase
>> *-JQ Microsistemas
>> *-809-747-2787
>> * " Si deseas lograr cosas excepcionales debes de hacer cosas fuera de lo
>> comun"
>> *-------------------------------------------------------*
>>
>>
>>
>>
>>>From: Raúl Andrés Duque <raulandresduque(at)hotmail(dot)com>
>>>To: <pgsql-es-ayuda(at)postgresql(dot)org>
>>>Subject: [pgsql-es-ayuda] Alternativa para manejar variables de sesion
>>>Date: Fri, 27 Oct 2006 03:46:46 -0500
>>>
>>>Cordial Saludo Listeros.
>>>
>>>Según he leido postgresql aún no implementa variables de sesión ...
>>>alguien conoce alguna alternativa?
>>>
>>>Lo que se me ocurre es que cada que se inicie una sesion, se grabe a una
>>>tabla el id de la sesion junto con el valor que quiero almacenar. Cuando
>>>requiero este valor lo consulto en esa tabla por el id de la sesion
>>>activa. Cuando se cierre la sesion borro el registro correspondiente.
>>>
>>>Para esta implementación tengo dos dudas.
>>>1. Cómo obtengo el id de la sesion/conexión activa?
>>>2. Cómo pueedo crear una función que se ejecute antes de que se cierre
>>>una sesión/conexión, algo así como un trigger pero que se ejecute cuando
>>>se cierra una sesion/conexion.
>>>
>>>Gracias.
>>>
>>>Atentamente,
>>>
>>>RAUL DUQUE
>>>Bogotá, Colombia
>>>
>>>
>>>---------------------------(fin del mensaje)---------------------------
>>>TIP 1: para suscribirte y desuscribirte, visita
>>>http://archives.postgresql.org/pgsql-es-ayuda
>>
>> _________________________________________________________________
>> De todo para la Mujer Latina http://latino.msn.com/mujer/
>>
>>
>
>
> ---------------------------(fin del mensaje)---------------------------
> TIP 6: ¿Has buscado en los archivos de nuestra lista de correo?
>
> http://archives.postgresql.org/pgsql-es-ayuda
>

On 10/28/06, Raúl Andrés Duque <raulandresduque(at)hotmail(dot)com> wrote:
> Que tal Edwin ... esto de las variables de sesion no es nada que me haya
> inventado ... algunos motores las implementan.
>
> Un ejemplo sencillo de su utilización:
> Se tiene una aplicación donde TODOS los usuarios acceden a la DB con un
> usuario genérico y es la aplicación la que controla la parte de permisos
> (usuario en la aplicación) ... si quisieras montar un trigger para por
> ejemplo auditar cambios de estado, cómo podrías saber que usuario realizó la
> operación? Una alternativa es al iniciar la sesión se define una variable
> con el id del usuario ... cuestion que cualquier trigger puede hacer uso de
> esa variable.
>

grabas en una tabla la ip de la maquina cliente y el usuario de la aplicacion?

--
Atentamente,
Jaime Casanova

"Programming today is a race between software engineers striving to
build bigger and better idiot-proof programs and the universe trying
to produce bigger and better idiots.
So far, the universe is winning."
Richard Cook

On 10/29/06, Raúl Andrés Duque <raulandresduque(at)hotmail(dot)com> wrote:
> Mi aplicacion tiene una tabla de usuario, donde guardo el nombre y clave.
> Cuando se inicia la aplicacion se conecta con un usuario generico y valida
> el usuario y clave que digita el usuario contra esta tabla. Ya de ahí para
> adelante los permiso los maneja la aplicación con otras tablas que tiene los
> perfiles de permisos.
>
> No se si escuchaste pero me pareció una buena solución para mi poblema la
> que dió el compañero Jame Charles, crear una tabla temporal !!!
>

no habia visto esa respuesta. pero tienes razon es una mejor solucion,
para un aplicativo que va a mantener una conexion permanente a la
base. pero en el caso que menciona Javier (aplicaciones web) no
podrias usar una tabla temporal

--
Atentamente,
Jaime Casanova

"Programming today is a race between software engineers striving to
build bigger and better idiot-proof programs and the universe trying
to produce bigger and better idiots.
So far, the universe is winning."
Richard Cook

El Sábado, 28 de Octubre de 2006 23:29, JA nos dijo ...:
> Un caso mas concreto es en las aplicaciones Web donde el servidor Web por lo
> general se conect a la base de datos con un solo usuario ( usuario de base
> de datos ) y claro los usuarios se distinguen unos de otros con usuarios de
> aplicación. En este sentido si es necesario usar variables de sesion.

Si haces una aplicación para la web, casí seguro que utilizas PHP, ASP, J2EE,
etc.

Yo te hablaré de php, que es lo que mas conozco.

Cuando empezamos (por lo general) un script en PHP, este:
1 - Comprueba si existe alguna 'cookye' de sesión en el cliente web.
2 - Comprueba si esta registrada.
3 - Si ninguna de las opciones anteriores da resultado positivo, crea una
nueva 'cookye' y la envía al cliente web.

Todo esto mediante la función 'session_start()'.

Con esta 'cookye' el sabe que cliente quiere que, y no necesita decirle a la
base de datos quien pide la información.

--
----o---( )---o----
Saludos de Victor Lopez Sabio
v(dot)lopez(dot)s(at)ono(dot)com
--------oooo--------

El Sábado, 28 de Octubre de 2006 23:29, JA nos dijo ...:
> Es mas ... algunos sistemas cliente servidor, tambien usan conecciones de un
> solo usuario ( proxy user ) a la base de datos y se diferencian solamente
> por usuarios de aplicación.

Si lo que diseñas no es para la web ...

Se hacen códigos con transacciones cortas (recomendado).

El porque de las transacciones cortas tiene que ver con los interbloqueos
dentro del mismo usuario.

Si haces una SELECT no hay problema, ya que no cambias nada.

Si lo que haces es algo que si modifica (INSERT, UPDATE o DELETE), hasta que
no se cierre la transacción nadie mas (de ese usuario) podrá hacer nada (para
evitar inconsistencias.

Sin tablas, sin nada que no sea el bloqueo utilizado por el gestor.

(Confieso que lo explico, de lo que me acuerdo de cuando trabajaba con
Oracle ... pero supongo que es parecido en todos los gestores)

--
----o---( )---o----
Saludos de Victor Lopez Sabio
v(dot)lopez(dot)s(at)ono(dot)com
--------oooo--------