Dividir o banco de dados: é aconselhável?
Prezados,
Estou com a seguinte situação para ser definida:
- Tenho um aplicativo que é utilizado por várias empresas e, atualmente, este aplicativo único acessa as informações também em um banco de dados único gravando em cada um de seus registros a qual empresa cada registro pertence, assim, quando é necessário buscar as informações de uma determinada empresa, aplica-se um filtro (where) nas tabelas necessárias e pronto.
Este modelo facilita muito a questão da manutenção (1 aplicativo e 1 base de dados), mas, começo a ter problemas com a performance do sistema. Explico: como existe empresa que possui 200 registros em uma tabela e outra que possui 900.000 (a desproporção é esta mesmo), toda vez que a empresa "menor" precisa gerar um relatório ou coisa do tipo ela, necessáriamente processa os registros de todas as outras empresas.
- Como a tendência é que mais empresas passem a usar o aplicativo elevando, exponencialmente, a quantidade de registros, estou pensando se devo dividir o banco de dados em vários (um para cada empresa).
Desta forma, existem vários benefícios: - cada empresa com seu banco; backups individuais, acesso a menos dados da cada vez, possibilidade de dividir os bancos em servidores distintos etc. Porém, há também alguns inconvenientes: toda vez que alterar o banco, será necessário replicar a alteração em todas as bases; o Postgres passará a trabalhar com vários bancos simultêneos ao invés de um único; será preciso modificar a conexão do aplicativo para que a cada login "saiba" em qual banco deve se conectar etc.
E aí, alguma sugestão?
Grato,
Alexandre
Estou com a seguinte situação para ser definida:
- Tenho um aplicativo que é utilizado por várias empresas e, atualmente, este aplicativo único acessa as informações também em um banco de dados único gravando em cada um de seus registros a qual empresa cada registro pertence, assim, quando é necessário buscar as informações de uma determinada empresa, aplica-se um filtro (where) nas tabelas necessárias e pronto.
Este modelo facilita muito a questão da manutenção (1 aplicativo e 1 base de dados), mas, começo a ter problemas com a performance do sistema. Explico: como existe empresa que possui 200 registros em uma tabela e outra que possui 900.000 (a desproporção é esta mesmo), toda vez que a empresa "menor" precisa gerar um relatório ou coisa do tipo ela, necessáriamente processa os registros de todas as outras empresas.
- Como a tendência é que mais empresas passem a usar o aplicativo elevando, exponencialmente, a quantidade de registros, estou pensando se devo dividir o banco de dados em vários (um para cada empresa).
Desta forma, existem vários benefícios: - cada empresa com seu banco; backups individuais, acesso a menos dados da cada vez, possibilidade de dividir os bancos em servidores distintos etc. Porém, há também alguns inconvenientes: toda vez que alterar o banco, será necessário replicar a alteração em todas as bases; o Postgres passará a trabalhar com vários bancos simultêneos ao invés de um único; será preciso modificar a conexão do aplicativo para que a cada login "saiba" em qual banco deve se conectar etc.
E aí, alguma sugestão?
Grato,
Alexandre
Alexandre Thees
Curtidas 0
Respostas
Wilson Junior
06/02/2011
Isto pode variar muito, pois se você possui um servidor "porrada" e definir corretamente os seus SQL's de consulta e definir também índices para as tabelas, o que pode melhorar e muito a perfoprmance da consulta SQL's, você pode utilizar somente um banco de dados, agora, se você possui um servidor "meia-boca" será necessário ter vários banco de dados, para o caso de backup individual também, mas dependendo da quantidade de banco de dados que você tiver, terá que ter um servidor "porrada também".
Espero ter colaborado.
Espero ter colaborado.
GOSTEI 0