Criação de bancos em uma aplicação de serviço

Na minha opinião, se nenhum cliente tem relação com outro cliente, tipo Matriz e Filial, então cria um banco para cada um.

Entao mas a manutenção nao fica complicada na hora de fazer uma atualização na estrutura de 1 tabela, eu tenho de replicar para 200 ou tambem na hora de adicionar um cliente novo no sistema tenho de criar um BD usuario e tabelas?

o problema de criar um banco para cada Cliente é a complexidade adotada, pois terá de identificar qual cliente está logando e então direciona-lo para o banco certo, a manutencao como vc mesmo citou e etc.

porem ganha-se em performance, pois cada cliente irá performar as queries somente em seus proprios dados. E tambem na segurança imagine que em alguma query vc esqueça de colocar o WHERE para filtrar os registros pelo Cliente.

abrassss

Opa,
Cara, eu não faria bases individuais para cada empresa.

Não sei qual é o banco de dados que vc pretende usar…
Mas acredito que com um modelo relacional inteligente e utilizando algumas ferramentas do banco vc consegue montar algo bem estruturado e seguro.

Eu me basearia em um modelo relacional bem feito, utilizando todas as formais normais e tal…
Além disso, criaria acessos baseados no usuário do banco.
Criaria Views contendo os registros exclusivos da empresa. Essas Views estariam visíveis apenas para os usuários de suas respectivas empresas…

Enfim…
Algo que segue essa linha…

Como funciona a aplicação? É uma aplicação comum a todas as empresas? Cada empresa entra com seu login e ve suas respectivas informacoes?
Ou cada empresa possui uma aplicação diferente, ou funcionalidades diferentes?

Entao a aplicação é igual para todos os clientes, tanto que só tenho um codigo fonte da aplicação, o que iria variar seria apenas o conteudo dos registros, mas a estrutura seria a mesma, pensei mais no desempenho, o que seria pior, 200 BDs com 1 acesso cada ou 1 BD com todos os clientes tendo 200 acessos?

Vou utilizar MySQL em servidor linux

a principio eu faria da maneira convencional, a nao ser que seu volume de dados seja tao alto que impacte na performance.

com relação a views nao vejo pq de cria-las se vc estiver usando um ORM.

romarcio vc já desenvolveu alguma aplicação com sharding de banco?

abrasss

Cara,

Com relação a desempenho em consultas, inserts, deletes e updates…
Tudo é uma questão de como vc irá estruturar seus relacionamentos e índices.
Atualmente os banco de dados desenvolveram algoritmos que aprimoram a performance de consultas de forma inteligente e transparente ao usuário.
Portanto, acredito que neste aspecto não há com o que se preocupar.

Acredito que a preocupação deve estar nos aspectos de trafego de rede, utilização de memória do servidor e espaço em disco rígido.
Se vc for criar 200 instancias ou base de dados, vc replicará 200x metadados e outras informações exclusivas do MySQL.
Além disso, ao invés de carregar 1 MySQL em memória, vc carregará 200 MySQL…
Quantos servidores seriam necessarios? Quanto de memória, hd? Seria necessário uma virtualização? Enfim…

E com relação a alterações no aplicativo ou base de dados?
Vc terá de alterar, no mesmo ponto, 200 instancias…
O processo de manutenção do banco de dados será 200x mais lento…
Obvio que podem ser criados scripts e tal… mas será que o esforço vale a pena…

Eu pensaria nesses aspectos…
Ficaria com a opção de 1 base de dados…
E só para desencargo, faria um teste e tentaria rodar uns 10 juntos, só pra ver oq rola…

Blz vou optar por 1 banco apenas e utilizar um IdInquilino nas tabelas do meu Bd, li a edicao 92 da java magazine e vi algo sobre o hibernate shards, é possivel utilizar com JPA e Spring 3?

já fiz alguns testes com spring 3 e foi td bem, nao coloquei em produçao.

mas usando a api do hibernate mesmo, nos projetos que participo nunca trocamos a implementação do orm x)

abrassss