Banco de dados com vários usuários

4 respostas
P

Pessoal, preciso de uma ajuda pra me ajudar a como melhorar (Ou encontrar)a solução para este problema:

Tenho um sistema em JSF, a view será a mesma para todos usuários, porém cada usuário por exemplo terá seu registros específicos, por exemplo, o usuário joao se loga, ele tem acesso a todas as tabelas do banco que o usuário fernando tem, ambos persistem os dados nas mesmas tabelas, tabelas como por exemplo: publicacoes e revendas, duas tabelas distintas.

Eu pensei na primeira solução: todo objeto usuário terá uma lista de publicações, com isso, a tabela publicacoes teria uma foreign key usuario_id, e cada publicacao teria uma lista de revendas.

Só que achei que esta solução ruin, digamos que cada usuário tenha 10000 publicações, eu ainda vou salvar em formato BLOB as publicações do usuário, e estas tabelas são apenas 2 de 15 tabelas, como será o banco de dados daqui a 5 anos por exemplo? e como será o acesso aos dados? O usuario quando procurar por suas publicações, o acesso ao banco ficará muito lento, correto? E a tabela não terá fim, crescerá indefinidamente. Como opção para banco de dados escolhi postgresql, por ser gratuito, oferecer os recursos que tdos conhecem e também teoricamente não ter limite de armazenamento.

A idéia eh ter um sistema rápido, com um banco de dados que tenha um retorno nas consultas rápido e que um usuário não possa visualizar nenhum dado de outro usuário.

Bom, alguma sugestão para esta solução? Como melhorar ou padrões que poderia aplicar?

PS: Uma coisa a ser levada em conta, a manutenção neste banco vai ficar complexa também, um dos motivos que achei ruin armazenar tudo em uma única tabela.

POR OUTRO LADO…

Pensie em ter vários bancos de dados, mas dai vai perder o dinamismo do sistema, onde o usuário se cadastra e já pode começar a upar seus documentos, pois teria necessidade de se criar um novo banco para cada usuário e não faço idéia de como gerenciar dinamicamente como o hibernate vai acessar e persistir os dados nos bancos.

Bem, foram as duas idéias que tive, se alguem puder me clarear melhor as hipóteses e melhorias, será bem vindo! Obrigado.

4 Respostas

bombbr

Amigo, não existe problema algum com a solução que vc descreveu, ela esta correta.

O acesso não será comprometido não, mas para isto você terá que tomar cuidados mínimos como indices (no mínimo), particionamento destas tabelas (caso sejam muito, mas muito grandes), e outras técnicas ninjas de DBAs

Claro que se um usuário tiver 10000 publicações vc não deve trazem todas as 10000 de uma única vez, para que isto não ocorra exija filtros nas consultas e paginação dos dados na apresentação ao usuário.

Campo BLOB? Sempre busque pela chave primária. NUNCA algo como SELECT CAMPO_BLOB from PUBLICACAO.

Banco de dados Postgresql, não posso opinar pois não o conheço. Sei que o Oracle dá conta do recado com a mão nas costas.

A solução de criar vários bancos é criar uma complexidade para algo simples.

Espero ter ajudado

P

bombbr, mto obrigado pelo esclarecimento geral!

Uma pequena dúvida, como assim particionar a tabela? vc ker dizer dividir? Voce pode me indicar algum material para leitura a respeito desta técnica? Obrigado!

bombbr

pirado18:
bombbr, mto obrigado pelo esclarecimento geral!

Uma pequena dúvida, como assim particionar a tabela? vc ker dizer dividir? Voce pode me indicar algum material para leitura a respeito desta técnica? Obrigado!

Particionamento de tabelas é uma técnica utilizada em banco de dados como Oracle e SQL Server (outros devem ter este recurso também), que divide fisicamente os dados em fragmentos menores. Sendo bem simplista é como se ao invés de armazenar dados de uma tabela em um único arquivo esta tabela é dividida em vários outros arquivos.

TABELA.dat
Particionando por data (exemplo):
TABELA-2008.dat
TABELA-2009.dat
TABELA-2010.dat

Logicamente não há diferença quando você fizem uma consulta como, SELECT * FROM TABELA, todos os registros serão retornados independente de como eles estão armazanados.

Agora se você consultar, SELECT * FROM TABELA WHERE ANO = 2009, esta consulta será otimizada, pois o acesso aos dados será mais rápido do que se a tabela não tiver particionada.

Só lembrando que esta técnica é utilizada quando o volume de dados é muito grande. Em alguns casos diferentes partições de uma mesma tabela são configuradas para serem armazanadas em discos físicos diferentes.

http://www.google.com.br/#hl=pt-BR&source=hp&q=oracle+partition+table&btnG=Pesquisa+Google&meta=&aq=f&aqi=&aql=&oq=oracle+partition+table&gs_rfai=&fp=d0695d298b6fbd23

http://www.postgresql.org/docs/8.2/static/ddl-partitioning.html

P

Obigado novamente, uma última pergunta:

Qual o limite de registos especificar para que a tabela seja particionada? a partir de qual valor seria interessante começar a particionar?

Obrigado.

Criado 2 de maio de 2010
Ultima resposta 3 de mai. de 2010
Respostas 4
Participantes 2