Re: dudas con schemas

Hola Fernando disculpa el no contestar antes, efectivamente las
conexiones son a través de un pool como bien dices, en cuanto al sistema
estamos haciendo todas las pruebas con centos y el postgres de base de
datos, conectado también tenemos un NAS con los discos para almacenar y
otro servidor con Centos también para el aplicativo web, etc. Para todo
esto estamos en fase de pruebas y desarrollo ya que lo damos a través de
un servicio y como bien dices hay que tener en cuenta bastantes cosas.
En cuanto a tener una base de datos por cliente aunque lo pensamos lo
hemos terminado desechando ya que seguimos teniendo en muchos clientes
el standalone bajo oracle y no queremos cambiar la estructura porque
hemos de mantener las dos.
Saludos.

Rodriguez Fernando escribió:
> Jose Alberto Sanchez Nieto wrote:
>> 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.
>>
> Hola, disculpa que pregunte, pero estuve por fuera de todo esto.
> Tu dices que tu aplicacion es web, por lo cual el pool de conexiones o
> la forma de conectar radica en un servidor.
> Una opcion que considero con poco impacto seria crear un base de datos
> para cada empresa, con lo cual las tablas las manejas como hasta ahora
> y solamente tendrias que cambiar el nombre de la base en el servidor.
> Por curiosidad que capacidad tiene el servidor en el que se encuentran
> las base de datos y que plataforma es, ya que un DW te consume muchos
> recursos .
> La conexión de los clientes como se realiza?, Cuantos procesos de DW
> tendras procesando en el servior web y cuantas consultas estimas por
> hora ó minuto?.
> Disculpa que sea curioso ya que, por lo que decis es un proyecto
> grande, que en un descuido o mala fortuna puede dejar los datos de los
> clientes expuestos o pero aun destruidos si ocurre una fatalidad con
> el servidor.
>
>
> Saludos Fernando
>

--
?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