From: | Jose Vasquez <cibercol(at)gmail(dot)com> |
---|---|
To: | Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org> |
Cc: | Carlos Bazán <infobaz(at)vtr(dot)net>, Ayuda <pgsql-es-ayuda(at)postgresql(dot)org> |
Subject: | Re: Funciones y esquemas |
Date: | 2009-05-29 23:42:30 |
Message-ID: | 98a673a80905291642q2fbcc343ga2817b6a695e595c@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-es-ayuda |
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
>
From | Date | Subject | |
---|---|---|---|
Next Message | Giorgio PostgreSQL | 2009-05-30 00:13:56 | Re: Consulta sobre Triggers |
Previous Message | Giorgio PostgreSQL | 2009-05-29 23:30:23 | Re: Consulta sobre Triggers |