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 > Eu entendi a sua preocupação. Porém se você tiver usuarios diferentes para cada instância no sistema, cada qual irá visualizar somente os dados que ele cadastrou. A não ser que esta database está sendo criada para atender alguma aplicação já pronta que você não tem a possibilidade de customizar.... Att. João Paulo Rieg _______________________________________________ pgbr-geral mailing list [email protected] https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
