Uns meses atrás comecei a desenvolver um sistema web. Semana passada ele ficou pronto: já está rodando num servidor de uma empresa e eles o aprovaram! O próximo passo agora será colocá-lo na web e adaptá-lo para receber vários clientes. Minha dúvida então é sobre o banco de dados. No programa, há uma tabela principal que recebe muitas linhas: cada cliente acrescentará, em média, mais ou menos 50 linhas por dia nessa tabela. Daí, da pra ver que se um dia eu tiver vários clientes, essa tabela ficará gigante em muito pouco tempo.
Minha pergunta é: qual seria a melhor arquitetura para esse BD? Uma única tabela ou criar uma para cada login? Só pra constar, eu acho que o mais correto é criar uma tabela para cada login do sistema: se um usuário ‘user’ for criado, o sistema cria a tabela ‘tabela_user’ e mantém seus dados nela.
Ah, estou usando Tomcat, Struts, JDBC e PostgreSQL.
[quote=cadocado]Só pra constar, eu acho que o mais correto é criar uma tabela para cada login do sistema: se um usuário ‘user’ for criado, o sistema cria a tabela ‘tabela_user’ e mantém seus dados nela.
[/quote]
Cruz credo, se você me vier com isso em uma entrevista de emprego, você nem passa da porta. Quantos clientes há na sua empresa? Se houver 1000 clientes você terá 1000 tabelas, e é isso que fica inviável.
Realmente loucura ter uma tabela para cada login. Além de diversas tabelas, a grande dificuldade fica a respeito das chaves (pk e fk) e fazer select deve ser um tanto complicado.
Para banco de dados só se recomenda criar tabelas diferentes caso os campos sejao muito diferentes.
Por exemplo no caso de ter clientes pessoa fisica e pessoa juridica. Mas neste caso utilizam-se tabela especializadora.
thingol, os clientes não vão poder de forma alguma ver qualquer tabela que não seja a sua, ou seja, nao haveria os problemas de pk, fk ou select que o jcmird falou.
Vou fazer outra pergunta: no SQL, como é a performance de uma busca de algumas poucas linhas ‘pingadas’ dentro de uma tabela de vários milhões de linhas? O sistema faz muitas buscas no banco, o que tornou o principal motivo de eu ter cogitado as tabelas separadas (não me preocupo muito com espaço). Ah, não vai haver muitos clientes.
o banco de dados sempre inicia a pesquisa pelo inicio da tabela e vai pegando o solicitado, somente quando a busca for concluida o resultado será mostrado.
[quote=cadocado]thingol, os clientes não vão poder de forma alguma ver qualquer tabela que não seja a sua, ou seja, nao haveria os problemas de pk, fk ou select que o jcmird falou.
Vou fazer outra pergunta: no SQL, como é a performance de uma busca de algumas poucas linhas ‘pingadas’ dentro de uma tabela de vários milhões de linhas? O sistema faz muitas buscas no banco, o que tornou o principal motivo de eu ter cogitado as tabelas separadas (não me preocupo muito com espaço). Ah, não vai haver muitos clientes.
Obrigado, pessoal. [/quote]
Para isso você cria índices na sua tabela com os campos que são mais utilizados como filtros em suas pesquisas, então o SGBD irá utilizar esses indices para acessar os dados pertinentes a sua pesquisa mais rapidamente. Esse processo faz parte do que o pessoal costuma chamar de tunning do Banco de dados, para dar maior agilidade as suas pesquisas.
Não vejo necessidade de criar várias tabelas. Se você fizer isso, e precisar gerar estatísticas da sua base por exemplo, terá que ler dezenas de tabelas, e toda vez que criar uma nova terá que alterar essas estatísticas, ou então criar algum mecanismo que agregue as tabelas de forma dinâmica, ou seja, quem tiver que dar manutenção nisso depois irá lembrar de você com muito carinho. O pessoal fazia isso no tempo do Clipper, eu mesmo trabalhei em uma empresa que tinha várias versões e instalações do mesmo sistema, e no dia que tivemos que migrar para outro sistema unificado foi uma tremenda dor de cabeça.
mjmendes, muito esclarecedora sua resposta!
BD é uma das áreas que não gosto de estudar, mas como tenho que aprender para esse projeto, agradeço a todos pela ajuda! :idea:
[quote=cadocado]thingol, os clientes não vão poder de forma alguma ver qualquer tabela que não seja a sua, ou seja, nao haveria os problemas de pk, fk ou select que o jcmird falou.
Vou fazer outra pergunta: no SQL, como é a performance de uma busca de algumas poucas linhas ‘pingadas’ dentro de uma tabela de vários milhões de linhas? O sistema faz muitas buscas no banco, o que tornou o principal motivo de eu ter cogitado as tabelas separadas (não me preocupo muito com espaço). Ah, não vai haver muitos clientes.
Obrigado, pessoal. [/quote]
Só repetindo: achar algumas linhas dentro de uma tabela com vários milhões de linhas, se os índices forem bem projetados, é muito rápido. Você já ouviu falar de B-trees (não binary trees)? Tipicamente, nesses casos, você terá apenas 2 ou 3 acessos ao disco para achar uma linha em um milhão de linhas.
Que idéia de girico eim? criar tabelas dinamicamente pra cada usuário =Z
O pior é que essa idéia é relativamente comum.
Desencana disso, use a tabela “padrão” mesmo e estude mais sobre índices.
[quote=clone_zealot]bem, eu já vi bastante é o inverso: fazer um único e grande tabelão com muitas entidades…
esquemas por usuário é novo pra mim…
[/quote]
São casos diferentes, ambos errados no meu ponto de vista.
Assim como vejo muita replicação desnecessária de dados, por exemplo, existe o cadastro de fornecedores com todos os campos de endereços, pra clientes idem e assim por diante, cada tabela tem todos os dados de endereço.
