Conforme já foi dito, ter por exemplo 100 bancos ou até mesmo 100 schemas diferentes, irá lhe custar tempo para atualizar as tabelas caso você adicione alguma nova coluna, ou até mesmo faça alteração em alguma function().. pois terá que atualizar uma a uma.. a não ser que você faça algum script que automatize isso...
Renato Em 19 de novembro de 2012 10:38, Toty Ypiranga <[email protected]>escreveu: > Gostaria de agradecer a todos pelas contribuições e me desculpar pela > demora na resposta, pois fiquei off-line neste feriado. > > Com relação a colocação do Joao Paulo Rieg > > “Utilizando de teorias de sistemas, e seguindo a linha de raciocínio do > Euler > e da Monica, não seria muito mais apropriado criar a estrutura com um > esquema, e nas tabelas fazer a distinção a que usuarios os registros > pertencem?” > > > A estrutura de relacionamento do sistema seria relativamente simples. > Eu poderia criar uma relação de um para muitos entre a tabela usuário > e tabela dna e fazer um inner join simples para exibir apenas as > sequências genéticas de determinado usuário. Mas essa solução esbarra > na questão da privacidade. Pois posso ter um pesquisador da usp > estudando o genoma de um mosquito transmissor de uma patologia > qualquer e querer usar o sistema. Em paralelo posso ter um medico em > um hospital em Brasília que está realizando um estudo de mutação > genética e comparando amostras de dna de indivíduos diferentes. Ambos > podem querer usar scripts em perl prontos para realização de tarefas > de bioinformatica, ou, usar algum device para conectar no sistema como > uma maquina de PCR (um método para a criação de múltiplas cópias de > DNA) que entenda o padrão BioSQL, A ideia de utilizar o BioSQL é > justamente manter compatibilidade com outras soluções. > > > Logo a questão da privacidade torna-se muito importante. > > > O maior grau de privacidade e o isolamento total criando uma base para > cada usuário, mas como já foi mencionado pela Monica, isso aumentaria > o custo de manutenção do sistema, além de uma enorme redundância de > estruturas repetidas. > > A ideia de usar uma modelagem Multi-Tenant (Sugestão do Flavio) me > agradou bastante. Poderia usa-la na forma de Shared Database, > Separate Schemas (cenário 2) e como sugeriu o Euler migrar parar uma > base de dados para cada usuário (cenário 1). > > Antes que eu me esqueça o sistema contará inicialmente com 100 > usuários, podendo ter n usuários depois, apesar de não existirem > tantos biólogos e médicos mundo afora posso facilmente ver meu sistema > com 1000 usuários. E isso me leva a necessidade manter constante > vigilância no servidor para quando o mesmo atingir 50% de sua carga > alugue outro servidor e comece uma estrutura de High Availability and > Load Balancing. > > Em 19 de novembro de 2012 01:33, Joao Paulo Rieg > <[email protected]> escreveu: > > > > > > On 16-11-2012 12:09, Toty Ypiranga wrote: > >> Estou desenvolvendo um sistema de biotecnologia, na qual usuários > >> poderão se cadastrar livremente (publico) e armazenar suas sequências > >> de DNA e usar o sistema para uma serie de tarefas como alinhar > >> sequencia calcular peso molecular do DNA e etc... Como estou usando > >> biosql (conjunto de schemas e funções para padronização de base de > >> dados genômicas) com postgres emergiu a duvida sobre qual cenário > >> teria um melhor desempenho. > >> > > Os dois cenários tem vantagens e desvantagens. A principal pergunta é: > qual > > a > > quantidade de usuários você espera? > > > >> Cenário: 01 – uma base de dados para cada usurário; > >> > >> neste cenário o usuário se cadastra e o sistema cria uma base de dados > >> com o conjunto de tabelas do biosql; > >> > > Vantagens > > > > * isolamento total; > > * catálogo pequeno (um catálogo por BD). > > > > Desvantagens > > > > * número alto de BDs significa número alto de conexões. > > > >> > >> Cenário: 02 – uma base de dados única para o sistema e um schema para > >> cada usuário; > >> > >> neste cenário criaria uma trigger na tabela usuario e cada novo > >> usuario cadastrado a trigger criaria um novo schema com as tabelas e > >> funções do biosql colocando o nome do schema com o id do usuario. > >> > > Vantagens > > > > * compartilhamento de objetos comuns; > > * número baixo de conexões (se estiver utilizando pool). > > > > Desvantagens > > > > * isolamento parcial (GRANT/REVOKE para cada novo usuário ou objeto); > > * catálogo inchado (número alto de objetos em um mesmo BD). > > > >> Diante dos cenários expostos acima, qual teria o melhor desempenho, ou > >> tanto faz, pois daria na mesma. > >> > > A resposta mais sensata seria: cenário mesclado. Utilizar o cenário 2 > até um > > número razoável (que você terá que descobrir) de usuários. O cenário 1 > será > > utilizado para expansão (quando cenário 2 atingir o limite > preestabelecido). > > > > > > > > > > Utilizando de teorias de sistemas, e seguindo a linha de raciocínio do > Euler > > e da Monica, não seria muito mais apropriado criar a estrutura com um > > esquema, e nas tabelas fazer a distinção a que usuarios os registros > > pertencem? > > Desta forma você pode criar views com a clausula WHERE > usuario=current_user > > e a mesma vai apresentar apenas as informações do usuario logado... > > Quanto ao volume de informações, acredito que se você tiver nesta > estrutura, > > íncides bem elaborados, não vai fazer o sistema perder a eficiência. > > Tenho trabalhado com tabelas em um ERP com mais de um bilhão de > registros e > > com performance superior ao esperado. Mas claro com indices bem > elaborados > > de acordo com a necesidade. > > Caso a estrutura atingir o limite preestabelecido utilize-se do cenario 1 > > para expansão. > > > > Att. João Paulo Rieg > > > > _______________________________________________ > > 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 >
_______________________________________________ pgbr-geral mailing list [email protected] https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
