Re: dudas con schemas

Hola Oscar, la verdad es que el tránsito desde Oracle a Postgres está
siendo bastante satisfactorio, la verdad es que bastantes de los
"problemillas" vienen más por culpa nuestra ya que al venir de Oracle
tendemos a "traducir" sin más ciertas cosas que tenemos asimiladas y en
muchos casos no es así, hay que cambiar el chip. En cuanto al
rendimiento estamos gratamente sorprendidos, lo nuestro es un
datawarehouse al que se accede desde un portal web, así que nuestras
consultas son bastante complejas y aquí se desenvuelve fenomenal,
nuestra experiencia es un poco sesgada ya que es muchas cargas por la
noche en batch, y luego a lo largo del día sobre todo consultas para los
análisis, nosé que tal irá en los oltps aunque por lo que leo bastante
bien. Lo que es una maravilla es poder meterle mano en programación
prácticamente desde el lenguaje que quieras además de otras cositas que
te hacen la vida muy, muy facil.
Saludos.

Oscar Sanchez Martin escribió:
> Hola leyendo en tus foros he visto tu mensaje y quería pregutarte como valoras el postgress viniendo desde Oracle, nosotros estamos en la misma situación que tu mas o menos y hemos empezado a hacer pruebas de trasvase de datos y procedimiento, pero todavía no lo hemos hecho de rendimioento.
> De lo que comentas, yo habia pensado hacerlo asi como tu comentas, separando tablas y datos en distintos schemas y tablespaces .Me gustaría me dieras tu opinión al respecto del rendimiento del postgress y como lo ves.
> Gracias, otra cosa que podias plantearte es instalar el oracle xe, que es gratuito, lo único malo es que como mucho puedes tener 4gb de datos.
>
>
> -----Mensaje original-----
> De: pgsql-es-ayuda-owner(at)postgresql(dot)org [mailto:pgsql-es-ayuda-owner(at)postgresql(dot)org] En nombre de Jose Alberto Sanchez Nieto
> Enviado el: viernes, 01 de febrero de 2008 18:20
> Para: pgsql-es-ayuda(at)postgresql(dot)org
> Asunto: Re: [pgsql-es-ayuda] 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