Re: Funciones y esquemas

From: Carlos Bazán <infobaz(at)vtr(dot)net>
To: pgsql-es-ayuda(at)postgresql(dot)org
Subject: Re: Funciones y esquemas
Date: 2009-05-30 00:17:39
Message-ID: 200905292017.39939.infobaz@vtr.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-es-ayuda

Efectivamente, me interesaría mucho saber los problemas que tuvo Alvaro con un
modelo así, ya que para nosotros hacerlo de esa manera sería una excelente
solución.

Bueno, a la espera de los comentarios de Alvaro entonces...

Gracias

El Friday 29 May 2009 19:42:30 Jose Vasquez escribió:
> Nosotros utilizamos un sistema similar, inicialmente se trata de dividir la
> informacion por algun criterio en diferentes esquemas, por ejemplo el
> esquema o1p1 para la organizacion o empresa numero 1 para el periodo numero
> 1, el tiempo que dicho periodo representa se encuentra en una tabla llamada
> periodos; El esquema o1p2 para los datos de la organizacion 1
> correspondientes al periodo 2, etc.
>
> Hemos generalizado este sistema y escrito los programas para que se creen
> las funciones, triggers, para cada esquema.
>
> Inclusive lo hemos dejado abierto para que se pueda dividir por otros tipos
> de criterios como por ejemplo el tipo de informacion digamos
> correspondiente a comercial o a contable, etc.
>
> Sobre este sistema tenemos basado todo desde hace unos 5 a~nos y nos ha ido
> bien. Siempre activamos el parametro constraint_exclusion en el
> postgresql.conf.
>
>
> bueno, talvez olvide mencionar que las diferentes tablas heredan dentro de
> cada organizacion o del esquema publico dependiendo de la necesidad
> particular. Por ejemplo un listado de clientes hereda de cada organizacion,
> mientras un listado de cuentas contables puede ser comun a todas las
> organizaciones, etc.
>
>
> Lo 'unico que hechamos de menos es que postgres no nos permite indices que
> sean comunes a todas las divisiones de una tabla y esto es importante
> porque un mismo dato puede repetirse en una tabla contiene la misma
> informacion, sino que simplemente esta dividida por efectos de velocidad.
> Por ejemplo las facturas de un mes no se podrian repetir con las facturas
> de otro mes, y finalmente lo manejamos, pero idealmente postgres deberia
> respetar los indices.
>
> Bueno, me gustaria saber porque Alvaro considera p'esimo este dise~no, me
> parece importante su opinion y pues si Carlos considera podemos hablar mas
> en detalle el tema.
>
> Jos'e VASQUEZ
>
>
>
> 2009/5/29 Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org>
>
> > Carlos Bazán escribió:
> > > Estoy trabajando en una base que almacenará datos de muchos clientes,
> >
> > entonces
> >
> > > por una cuestión organizacional voy a crear para cada cliente un
> > > esquema
> >
> > con
> >
> > > las mismas tablas (y estructura) usando números, por
> > > ejemplo "1".tabla1, "1".tabla2, "2".tabla1, "2".tabla2 etc.
> >
> > Este diseño es pésimo. Yo ya lo intenté hace algunos años y sólo me dio
> > problemas. Te recomiendo que tengas todo el mundo en un solo set de
> > tablas, que es a lo que llegué después de mucha lamentación, dolor,
> > aspirinas y código reescrito.
> >
> > --
> > Alvaro Herrera
> > http://www.advogato.org/person/alvherre
> > "Postgres is bloatware by design: it was built to house
> > PhD theses." (Joey Hellerstein, SIGMOD annual conference 2002)
> > --
> > TIP 10: no uses HTML en tu pregunta, seguro que quien responda no podrá
> > leerlo

In response to

Browse pgsql-es-ayuda by date

  From Date Subject
Next Message Cesar Erices 2009-05-30 00:37:20 Re: Consulta sobre Triggers
Previous Message Giorgio PostgreSQL 2009-05-30 00:13:56 Re: Consulta sobre Triggers