Re: dudas con schemas

Jose Alberto Sanchez Nieto wrote:
> 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
>>
>
Hola a que te referis con el standalone en Oracle?
Entendí que el postrgres va a contener todo lo que esta en Oracle, si no
es asi, que queda en Oracle y que se va a hacer en postgres?

Saludos Fernando