Quando falei sobre o maior número de conexões me referia ao fato de cada
cliente se conectar a vários dbs.

E sim, eu li que as tabelas internas ficariam muito grandes, mas se não é
assim, então não vejo porque usar várias databases...

Obrigado pessoal, agora me resta saber se essa máquina nova vai aguentar
todo mundo pendurado somente nela, isso eu descubro daqui uns dias :P




On 8/22/07, Osvaldo Rosario Kussama <[EMAIL PROTECTED]> wrote:
>
> Jorge Vilela escreveu:
> > Então, eu pensei nisso, mas pesquisando um pouco uns dias atrás eu li em
> > algum lugar que o uso de muitos schemas e grande quantidade de dados em
> > cada dá um certo trabalho para manter porque as tabelas internas do
> > banco inchariam muito.
>
> Não sei se entendi corretamente mas com o aumento da quantidade de dados
> o que aumentará são as tabela de dados e não as tabelas internas (se é
> que você está falando do catálogo).
>
>
> >
> > Outro fator é que todo o banco é contido em um único arquivo que
> > cresceria muito, isso faz com que a leitura seja mais lenta.
>
> Os bancos de dados do PostgreSQL não são mantidos em um único arquivo.
> Veja:
> http://www.postgresql.org/docs/8.2/interactive/storage-file-layout.html
>
>
> >
> > Mas com certeza usando vários dbs aumentariam o número de conexões...
>
> Você quer dizer o contrário não é? Utilizando um único banco de dados
> você aumentará a quantidade de conexões nesse banco. Se forem vários
> bancos as conexões estarão distribuidas entre cada um deles.
>
>
> >
> > Será que é mesmo verdade que se deve evitar o uso de muitos schemas
> > grandes no postgres?
>
> Se você tem cópias de tabelas mantidas em seus diversos bancos de dados
> e necessita manter a integridade entre elas então é melhor utilizar
> esquemas. Se seus bancos de dados são totalmente independentes então é
> melhor mantê-los separados.
> Analise sob o aspecto da integridade dos dados e seu peso nos sistemas.
>
>
> >
> >
> >
> > On 8/22/07, *Pablo Sánchez* <[EMAIL PROTECTED]
> > <mailto:[EMAIL PROTECTED]>> wrote:
> >
> >     O ideal seria realmente o uso de schemas e centralização de
> >     informação. Se você mantiver diversos banco de dados, para cada
> bando
> >     terá que abrir uma conexão, ou então ficar mudando o tempo todo de
> >     banco em uso nas suas queries, o que pode causar facilmente erros.
> Se
> >     você tem tabelas compartilhadas entre os sistemas, melhor
> centralizar
> >     tudo mesmo. Aí, você pode aumentar o número de conexões simultâneas
> >     sem maiores problemas.
> >
> >     Em 22/08/07, Jorge Vilela< [EMAIL PROTECTED]
> >     <mailto:[EMAIL PROTECTED]>> escreveu:
> >      > Olá pessoal!
> >      >
> >      > Onde trabalho temos hoje 3 servidores (não conheço bem a
> >     configuração deles,
> >      > sei que não são tão bons se comparados a muitos por aí), e agora
> >     estamos com
> >      > uma v40 com 8gb mem sobrando.
> >      >
> >      > Então surgiu a idéia de migramos os bancos dessas 3 máquinas para
> >     essa v40
> >      > para unificar o maior número possível de tabelas que são usadas
> >     em vários
> >      > sistemas sem precisar de replicação.
> >      >
> >      > Para programação usamos PHP e um pouco de JAVA, mas ficariam em
> >     um servidor
> >      > separado, deixaríamos a v40 somente para o postgres.
> >      >
> >      > Minha dúvida é: Seria melhor separar uma database para cada
> >     sistema e
> >      > abandonar os schemas, ou colocar tudo logo em schemas já que
> >     estariam no
> >      > mesmo servidor? Assim eu usaria um schema/db só para as tabelas
> >     usadas por
> >      > várias sistemas também.
> >      >
> >      >
> >      > Algum de vocês já passou por isso?
> >      > Schemas podem ser mais fáceis de se usar mas dbs são melhores
> para se
> >      > gerenciar separadamente não é? Me corrijam se estiver falando
> >     abobrinha...
> >      >
>
>
> Osvaldo
> _______________________________________________
> pgbr-geral mailing list
> [email protected]
> https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
>
_______________________________________________
pgbr-geral mailing list
[email protected]
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Responder a