Re: dudas con schemas

El día 1/02/08, Jose Alberto Sanchez Nieto <albertosanchez(at)hiperusera(dot)es>
escribió:
>
> Ante todo dar las gracias por las contestaciones de Silvio, Gabriel,
> Nicola y Alvaro y disculpar la tardanza por la diferencia horaria pero
> es que escribo desde España y acabo de entrar a trabajar. Todas las
> opiniones son interesantes y las hemos discutido aquí (lástima que
> Gabriel no haya querido entrar en porqué no le parecía buena idea, lo
> hubiésemos apreciado), de todas formas desarrollo un poco más mi
> exposición. Quizás el problema es que venimos del mundo Oracle y estamos
> migrando todo ahora a Postgres de la misma forma y supongo que todo no
> se hace igual deseamos vuestra ayuda. Teníamos desarrollado un
> Datawarehouse que instalábamos en cada empresa a la que se lo vendíamos
> en sus servidores (hasta aquí nada nuevo), el problema nos surge cuando
> vamos a dar ese servicio nosotros en nuestras oficinas y en nuestro
> servidor/es, osea que instalamos en nuestro servidor la base de datos y
> cargamos el software vuelto a desarrollar para entorno web, pero claro
> tenemos que diferenciar los datos y no queríamos sobrecargar en el
> desarrollo de software esas distinciones (ni en los clientes ya que es
> web) sino que fuera la BD la que lo hiciera (como en Oracle).
> Originalmente cada una de las tablas tenían un campo para la empresa (y
> otro para organización ya que teníamos varias organizaciones con varias
> empresas relacionadas) que creo que es a lo que se refería Alvaro y en
> los servidores de cada una de ellas funcionaba bien pero al "juntarlas"
> todas en el nuestro simplemente es Inmanejable (hablando de teras de
> volumen de datos) y no de hablo de una tabla sino de muchas de ellas y
> eso que estaban particionadas y de todo, aún así inviable, además lo
> veíamos poco escalable por eso queríamos separar las tablas en schemas
> con sus tablespaces asociados a cada esquema, porque así podemos
> tenerlos en matrices de discos distintos (y hasta en servidores NAS) y
> si me falla uno se queda sin servicio esa organización que tiene
> asignado ese esquema y tablespace solamente, de la otra forma serían
> todas a la vez y el nivel de servicio sería muy bajo además de la mala
> escalabilidad como he dicho anteriormente. Además el diseño de las
> tablas en un datawarehouse difiere bastante de un oltp en el que todo se
> basa en la tercera forma, en el data no es así, está todo
> desnormalizado, esto hace que no veamos lo de las tablas comunes del
> amigo Gabriel.
> En resumen amigos: Todas las tablas, indices, funciones, etc las
> generamos inicialmente mediante scripts así que por eso pensamos que si
> creábamos el usuario y se le podía asignar por defecto un schema y sus
> tablespace, tras esto conectarnos con ese usuario y desde él ejecutar
> los scripts para generar todo, como tendría asignado en él sus schemas y
> sus tablespace pues todo se crearía ahí por defecto y si luego al
> conectarse pues ya por defecto encontraría todos los objetos a los
> cuales se referenciara desde cualquier función ó cualquier código de la
> aplicación sin tener que indicar el esquema por delante ya que era
> ímplicito por la conexión, y así tener separados por lógica de base de
> datos la tabla ventas de la empresa A de la tabla ventas de la empresa
> B, simplemente por la conexión ya la encontraría la que le corresponde
> en su schema, además de los beneficios que ya comenté anteriormente.
> Perdonar todos por el ladrillo, siempre he pecado de no sintetizar,
> agradecemos sus comentario, sugerencia y sobre todo "rectificaciones" ;-)
> .
> Saludos a todos.
>

¿Por qué no una base de datos por cliente? Creo que es más fácil
administrarlo y más seguro. La base de datos la eligirías al momento de
conexión desde el cliente.
También te permitiría tener distintas instancias de postgres en un servidor
grande.

De todas formas, poniéndole un schema por default al usuario, también
funcionará.

Saludos!
Silvio

--
Silvio Quadri