Re: dudas con schemas

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.

--
?José Alberto Sánchez Nieto
Responsable Dpto. Informática

Hiper Usera, S.L.
C.I.F. B-85139855
Avda. Principal s/n, Pol. Industrial Las Avenidas
Torrejón de la Calzada (Madrid)
C.P. 28991
Telf: 91 860 99 00
Fax: 91 816 00 00
email: albertosanchez(at)hiperusera(dot)es