Aplicação Web .Net com um banco de dados pra cada empresa

[Guilherme Mello]

Boa tarde pessoal,

tudo bem? Eu estou começando um desenvolvimento de um novo site aqui na empresa em que trabalho, e já chegou pra mim o primeiro caso de uso já com a demanda de criar um banco_comum e depois vários banco_xxxxx onde xxxxx é o código de cada empresa...

Eu tenho liberdade e talvez até autonomia para poder questionar e mudar isso caso seja necessário.

Gostaria de saber se alguém já trabalhou assim e quais são os prós e contras de se fazer uma aplicação que teria um banco pra cada empresa cadastrada e um "master"...

E onde eu colocaria essa parte de diferenciação dos bancos? digo, onde eu iria definir a connection string com o banco, já que mudaria de empresa pra empresa?

Por que não fazer como todas as vezes q eu sempre vi, um banco apenas com os devidos relacionamentos para separar os dados de uma empresa da outra?

Obrigado desde já e desculpem a ignorância!

--
Guilherme Mello

[Marcus Alexandre Silva]

Tudo depende sempre do cenário.

A principal vantagem deste modelo é que uma empresa Y com 5 milhões de registros em uma tabela não compartilha a mesma tabela da empresa X que tem 2 registros do mesmo tipo, as vezes até, de acordo com o cliente, pode ter seu próprio servidor. 

No seu caso, o banco de dados principal precisa ter uma tabela de empresas e respectivas configurações (Connection Strings). Também é bom neste banco centralizar as informações de administração (usuários, perfis, segurança, logs de uso e de cobrança, se for SaaS).

A parte mais chata é o versionamento dos bancos, principalmente se seu software trabalhar com campos customizados nas tabelas, se não for bem planejadinho é um Deus nos acuda....

--
Você recebeu esta mensagem porque faz parte do grupo .Net Architects hospedado no Google Groups.
Para postar envie uma mensagem para dotnetar...@googlegroups.com
Para sair do grupo envie uma mensagem para dotnetarchitec...@googlegroups.com
Para mais opções visite o grupo em http://groups.google.com/group/dotnetarchitects?hl=pt-br
---
Você está recebendo esta mensagem porque se inscreveu no grupo ".Net Architects" dos Grupos do Google.
Para cancelar a inscrição neste grupo e parar de receber seus e-mails, envie um e-mail para dotnetarchitec...@googlegroups.com.
Para obter mais opções, acesse https://groups.google.com/groups/opt_out.
 
 

[Gustavo Cruz]

A não ser que o volume de dados por empresa seja exorbitante (falando aqui de 7 dígitos pra cima), eu não usaria multi-banco. 

Versionar isso como o colega aí em cima disse vai ser um parto.

Isso vendo pelo contexto puro de organização de dados....você pode ter outros N fatores que te favoreça o uso de DB´s separados.

Se de fato o problema for performance, eu ainda assim arriscaria uma única instância. Ainda mais na era da nuvem...

2013/3/26 Marcus Alexandre Silva <inf.marcu...@gmail.com>

[Guilherme Mello]

Valeu pelas respostas pessoal... acho que nem vai chegar a ter esse problema de muitos dados não... vou conversar mais com o analista aqui

acho que me passaram assim pq a empresa aqui já tinha essa cultura em outros sistemas que ela fez, onde a massa de dados é gigante, mas não acho que vai ser o problema desse projeto... os bancos iam todos ficar até dentro do mesmo servidor...

com relação às alterações, eu já estava até preocupado com isso, imagina ter q rodar esses scripts em todo mundo, aí um cara esquece, e começam os problemas.

Obrigado Gustavo e Marcus!

--
Guilherme Mello

2013/3/26 Gustavo Cruz <gfcm...@gmail.com>

[Renato Cantarino]

"imagina ter q rodar esses scripts em todo mundo, aí um cara esquece"

Multitenancy manual?

Att,

Renato Cantarino

[Priscila Mayumi Sato]

O que você considera "uma base gigante"?

PS: eu apoio o que os colegas ja disseram :D

Priscila Mayumi Sato

Twitter: @MayogaX

[Guilherme Mello]

uns 54GB só pra uma empresa.

mas isso não vai chegar nem perto do projeto que eu to agora...

2013/3/27 Priscila Mayumi Sato <mayum...@gmail.com>

gigante

--
Guilherme Mello

[dm.ga...@gmail.com]

O tamanho não importa muito. Você separar por arquivo usando uma chave como, por exemplo, enterprise id e suas queries não sofreram tanto.

Agora tem que ver customização e evolução de versão. Por exemplo, meu cliente A pagou um pacote de funcionalidades que não faz sentido para o cliente B. Eu vou atualizar a base única e o aplicativo para os dois?  Vou congelar os clientes por versão?

São coisas que sempre é bom pensar. Normalmente, EU crio uma primeira versão que compartilha o banco entre vários clientes, e conforme os requisitos vão chegando eu  adapto. 

Deivison M. Gandini
dm.ga...@gmail.com | msn: dm_ga...@hotmail.com
Before printing, think about your responsibility and commitment to the ENVIRONMENT!
Antes de imprimir pense em sua responsabilidade e compromisso com o MEIO AMBIENTE!

2013/3/27 Guilherme Mello <guilherme....@gmail.com>

--
Guilherme Mello

--

[Priscila Mayumi Sato]

Só perguntei do tamanho porque ele disse que era gigante, fiquei curiosa.

Eu criaria já tudo separado desde o inicio. Se um cliente precisa de um campo novo você vai adicionar e todo irão poder acessar aquele campo mesmo que não precisem?

Versionar...versionar é o de menos, digo, vai ser viável e possível do mesmo jeito. Controlar o que é de quem é o maior problema.

[Gustavo Cruz]

Não faz sentido separar DBs por nível de customização, isso se resolve na aplicação.

Se forem apps completamente diferentes sim, mas eu não vejo nenhuma vantagem em separar DB´s quando se tem a mesma aplicação para vários clientes, neste caso um produto ou SaaS.

[daniel carli]

http://en.wikipedia.org/wiki/Multitenancy

Daniel Carli

dcrlz.tumblr.com

[Priscila Mayumi Sato]

Okay, okay, desisto.

dando uma olhada para isso aqui: http://msdn.microsoft.com/en-us/library/aa479086.aspx

eu me pergunto porque nesse caso não usar noSql então.

(au ainda acho feio deixar dessa forma quevocês propõem, mas blz)

[Alexsandro]

Demorei, mas cheguei :P

Mas então, eu ja trabalhei pra uma empresa cujo o ramo de negocio era CMS/Portais.

A gente tinha banco de dados para cada cliente, eram em torno de 120 clientes, vou te falar uma coisa... era um nitido parto versionar estes banco de dados, pois na verdade não eram apenas 120 banco de dados, entao 120 x 3 = 360 databases pelo seguinte:

120 no ambiente de desenvolvimento.
120 no ambiente de holomogação.
120 no ambiente de produção.

Era um trabalho e tanto, a gente mantia um DBA so para tomar conta de versões de databases...

So que hoje eu pergunto a voces..... E aquele projeto no Visual Studio chamado "SQL Server xxxx Database Project", será que não melhora em 99% este problema de gerenciar versões de banco de dados?

[Eric Lemes]

Pessoal,

Meus 2 cents:

É bem mais fácil rodar numa base só, separando na estrutura das tabelas (Ex.: Tabela "Empresa") de qual empresa pertence o dado. É mais fácil manter a gestão de uma infra só, um procedimento de deploy só, mas obviamente nem tudo são rosas. Jà trabalhei num ambiente desta forma com algumas centenas de clientes corporativos, algumas milhões de usuários e algumas dezenas de milhares e registros. E pasmem, em SQL Server. Foi a primeira vez que eu vi um SQL Server chegando ao limite, principalmente no que tange a vazão de I/O. Com a melhoria do hardware, isso melhorou.

O grande trade off a ser feito aqui, é que vale a pena fazer isso desde que seja um código para todos os clientes. Você pode através de parâmetros, factories, etc, fazer partes diferentes da aplicação reagirem de forma diferente. Ex.: Um cliente tem uma data de entrega por pedido. Outro tem uma data de entrega por item de pedido. Você pode tratar isso com parâmetros.

O grande problema disso é que a complexidade da aplicação começa a ficar exponencial com o decorrer do tempo. Fica difícil de testar, de manter e são tantas variações de "sabores" da aplicação dada a criatividade de cada cliente que a aplicação fica gigante.

Com o tempo, você começa a ter problema com evolução de tecnologia. Por exemplo, você fez agora tudo em ASP.NET MVC 3, com SQL Server e .NET 4.0 usando um framework arquitetural. Daqui a 5-10 anos surgem novas tecnologias e tecnicas de desenvolvimento. Você não tem opção. Como tudo está numa base de código só, você só consegue subir de tecnologia, se portar tudo. 

Sempre vai ter aquele cliente que paga uma merreca por mês, que está usando um treco que só serve pra ele e a tua empresa vai ter que pagar do bolso dela pra você subir isso de tecnologia.

Se eu fosse começar um negócio desse tamanho hoje, eu utilizaria a seguinte linha de raciocínio:

- Usar e abusar de polimorfismo/strategy/inversão de dependência fazendo com que cada especificidade de cada cliente seja implementada numa classe específica dele de forma que o core da aplicação conheça somente uma abstração.

- Particionar o domínio de negócio, de forma que no exemplo acima eu possa ter dois módulos de pedido, cada um com sua estrutura completamente distinta de forma que cada cliente possa combinar os módulos para formar o seu "sabor" da aplicação

- Usar um conceito de SOA/ESB para fazer esses diferentes domínios se conversarem com o restante do sistema.

O principal motivador dessa quebra de domínio de negócio (que ainda não pude aplicar na prática) é justamente a questão da evolução tecnológica que eu comentei. Coisas novas ficam novas e coisas velhas ficam velhas. Você não é obrigado a portar todo o passado para uma tecnologia nova. Pode somente construir um pedaço de um domínio de negócio novo em tecnologia nova, manter o velho velho. Na experiência que vivi pessoalmente foi aqui que a coisa emperrou. Tudo começou a uma década e meia atrás em classic ASP e Delphi, que até hoje estão rodando firme e fortes, pq ninguém quer bancar o upgrade disso. Quando entram clientes novos sai sempre mais barato meter mais uma flag e um desvio na estrutura antiga, do que criar toda uma estrutura nova. As coisas novas nascem velhas e cada vez mais a estrutura fica mais paquiderme e difícil de evoluir.

Tem que ver se é o momento certo pra investir nisso. Se neste momento os clientes não tem tantas coisas específicas talvez não seja o momento, mas quando as customizações começam a torcer o sistema de uma forma que ele não foi feito pra atender  (o exemplo da data de entrega é um exemplo). Multitenancy é legal, mas tem um limite. Quando você tenta fazer uma estrutura que acomode coisas muito heterogêneas o negócio fica impossível de gerenciar.

O velho trade-off. Pagar mais caro agora e pensar num futuro sustentável ou comprar uma dívida técnica.

Abraço,

Eric

http://ericlemes.com

2013/3/29 Alexsandro <bagu...@gmail.com>