Usuário com melhor resposta
Estrutura do banco de dados em um cenário global.

Pergunta
-
Olá Amigos,
Eu tenho um cenário e preciso definir/redefinir a estrutura do banco de dados/schemas do meu projeto, mas tenho algumas dúvidas do que é o mais indicado a fazer.
Cenário:
Eu tenho uma aplicação na Web que será utilizada por centenas de empresas, aos quais possuem varios usuarios por empresa e possuo na modelagem da aplicação
algumas entidades, entre elas: Contas, Contatos, Oportunidades, Campanhas, Atividades, etc.. voltado para o segmento de CRM, além das entidades de Empresa e Usuarios.
Atualmente a minha arquitetura do banco de dados é a seguinte no SQL Server 2008 R2:
Banco CRM
Schema Comum:
Tabelas Empresas, Usuarios.
Schema Empresa X*:
Tabelas Contas, Contatos, Oportunidades, Campanhas, Atividades.
Schema Empresa Y*:
Tabelas Contas, Contatos, Oportunidades, Campanhas, Atividades.
* Ou seja, para cada empresa que usará a solução web, terá um schema contendo as tabelas que conterão os dados específicos de sua empresa.
Após bastante pesquisar que arquitetura seria a mais indicada para este cenário, onde se terá uma aplicação centralizada na Web e que poderá ser
usada por várias empresas diferentes, surgiu-me varias indagações sobre os conceitos:
1) Um fator negativo ao meu ver nesse caso é que para cada nova empresa precisarei ter uma forma "automatica" de criar o schema e os objetos do banco
para a nova empresa. Outro fato "ruim" é que qualquer atualização em alguma tabela ou objeto(procedure, view, etc), fora do schema comum, precisarei
ter uma forma de replicar a atualização para todos os schemas das empresas. Outra situação que precisarei ver é como criarei os backups dos dados de cada
empresa situados em seus respectivos schemas.
2) Por outro lado, se tudo estivesse em um único schema no banco de dados, imaginem a tabela de contatos armazenando todos os contatos de todos os usuarios de todas as empresas?
Fora isso, teria que ter em cada tabela a chave da empresa para questoes de filtros e separação dos dados, alem de sempre ter nos "selects" da aplicação um where indicando a empresa.
Outra coisa seria referente ao bkup/restore de um banco muito grande, contendo informações de todas as empresas nele..
Tenho essas e outras duvidas que estão surgindo em um cenario de uma aplicação deste porte e agradeço para podermos discutir para que eu possa tomar a melhor decisão..
Estava até vendo algo referente a bancos não relacionais(noSQL), referente a melhores solucões de problemas de escalabilidade, mas acredito que o SQL Server pode sustentar bem mesmo com um
crescimento rápido das informações.
Att.
Cristiano Testai- Tipo Alterado Roberto F FonsecaModerator sábado, 19 de janeiro de 2013 01:16 É uma pergunta, não uma discussão
Respostas
-
Cristiano,
Nunca trabalhei com um sistema que fizesse um uso de schemas da forma como você está falando e acredito que a manutenção do sistema pode ser um fator complicador, como você mesmo já percebeu.
Hoje, o sistema que eu trabalho faz uso do teu segundo caso e particularmente não temos problemas quanto à manutenção ou backup / restore (uma política de backup bem definida já resolve).
O tratamento por empresas será inevitável, seja utilizando o schemas ou um schema único, a diferença é o local do tratamento.
Espero ter ajudado...
[]'s
- Marcado como Resposta Ricardo Russo segunda-feira, 21 de janeiro de 2013 12:00
Todas as Respostas
-
Cristiano,
Nunca trabalhei com um sistema que fizesse um uso de schemas da forma como você está falando e acredito que a manutenção do sistema pode ser um fator complicador, como você mesmo já percebeu.
Hoje, o sistema que eu trabalho faz uso do teu segundo caso e particularmente não temos problemas quanto à manutenção ou backup / restore (uma política de backup bem definida já resolve).
O tratamento por empresas será inevitável, seja utilizando o schemas ou um schema único, a diferença é o local do tratamento.
Espero ter ajudado...
[]'s
- Marcado como Resposta Ricardo Russo segunda-feira, 21 de janeiro de 2013 12:00
-
Olá Logan,
Também estou analisando o segundo caso, pelas manutenções/bkups/atualizações nos objetos.. Acho que esse é o caminho realmente... e futuramente se a coisa crescer realmente.. aí veremos soluções para escalabilidade como particionamento de tabelas/indexação, entre outros..
Att.
Cristiano