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 <alvhe...@alvh.no-ip.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 -- TIP 3: Si encontraste la respuesta a tu problema, publícala, otros te lo agradecerán
