Devo usar um banco de dados por aplicativo ou compartilhar um único banco de dados entre vários aplicativos [fechado]

Eu tenho vários aplicativos, alguns que usam dados das mesmas fontes. É uma boa prática (ou quais são os prós / contras):

• deixe os dados em bancos de dados compartilhados por vários aplicativos

  1. economiza espaço, pois é necessário apenas um banco de dados
  2. complica a indexação, pois diferentes aplicativos têm diferentes necessidades de consulta

• importar dados diariamente para bancos de dados por aplicativo

  1. usa mais espaço, pois existem dados duplicados nos bancos de dados por aplicativo
  2. indexação mais fácil, pois cada aplicativo pode se concentrar em suas necessidades individuais

Posso ter deixado de fora outras vantagens / desvantagens, liste, se houver, e também como isso é feito no seu local de trabalho?

Atualmente, o espaço é barato, por isso aconselho o uso de um banco de dados por aplicativo.

Compartilhar um banco de dados entre vários aplicativos tem algumas sérias desvantagens :

• Quanto mais aplicativos usarem o mesmo banco de dados, maior será a probabilidade de você encontrar gargalos de desempenho e não conseguir dimensionar facilmente a carga conforme desejado . Os bancos de dados SQL não são realmente escaláveis. Você pode comprar máquinas maiores, mas elas não escalam bem em grupos!

• Os custos de manutenção e desenvolvimento podem aumentar : o desenvolvimento é mais difícil se um aplicativo precisar usar estruturas de banco de dados que não são adequadas para a tarefa em questão, mas precisam ser usadas como já estão presentes. Também é provável que os ajustes de um aplicativo tenham efeitos colaterais em outros aplicativos ("por que existe um gatilho desnecessário ??!" / "Não precisamos mais desses dados!"). Já é difícil com um banco de dados para um único aplicativo, quando os desenvolvedores não sabem / não podem conhecer todos os casos de uso.

• A administração se torna mais difícil: qual objeto pertence a qual aplicativo? Caos subindo. Onde devo procurar meus dados? Qual usuário tem permissão para interagir com quais objetos? O que posso conceder a quem?

• Atualização: você precisará de uma versão com o menor denominador comum para todos os aplicativos que a utilizarem. Isso significa que certos aplicativos não poderão usar recursos poderosos. Você terá que ficar com versões mais antigas. Também aumenta um pouco os custos de desenvolvimento.

• Concorrência: Você pode realmente ter certeza de que não há dependências cronológicas entre processos? E se um aplicativo modificar dados desatualizados ou que deveriam ter sido alterados por outro aplicativo primeiro? E os diferentes aplicativos que trabalham nas mesmas tabelas simultaneamente?

Comparado a isso, as importações de dados / processos ETL são quase sempre bastante diretas e simples. Carregue os dados quantas vezes for necessário, o espaço é barato. Você pode explicar a escalabilidade de cada aplicativo independentemente, ajustar e ajustar as estruturas conforme necessário e não haverá problemas de simultaneidade. Os efeitos colaterais também podem ser rastreados muito mais facilmente.

Edit: Gostaria de ressaltar, no entanto, que, como o @Saeed mencionou, se você pode encapsular manipulações de dados em um serviço que está normalmente disponível, é mais fácil compartilhar um banco de dados com vários aplicativos. Contanto que você não precise de acesso bruto, essa é uma abordagem muito boa.

Eu tive uma situação semelhante uma vez. Meu problema era criar três aplicativos, um para gerenciamento de inventário, um para gerenciamento de compras e outro para gerenciar usuários, ou seja, funcionários. Minha recomendação é não interromper os bancos de dados fisicamente por aplicativo ou uni-los fisicamente por aplicativo. Pelo contrário, a separação lógica do IMHO funciona melhor.

Por exemplo, todos os três aplicativos necessários para trabalhar com informações de funcionários. Os sistemas de estoque e suprimento usavam as mesmas informações de mercadorias e itens de estoque.

Criei um banco de dados compartilhado, no qual armazenava as informações de usuários e mercadorias. Então construí uma camada de serviço sobre ela e usei esses serviços em outros aplicativos. Para mostrar uma lista de todos os funcionários que estão agora na empresa, por exemplo, eu só precisava chamar um método do serviço, como GetOnWorkEmployees().

Também criei uma interface de usuário comum para interagir com usuários e mercadorias, que era um aplicativo da Web separado por si só.

Então, adicionando o que o @Falcon apontou, acho que você pode se beneficiar da centralização da funcionalidade comum entre aplicativos em um banco de dados.

Se esses aplicativos funcionarem com os mesmos dados - por exemplo, a mesma lista de produtos e clientes -, mantenha o banco de dados unido. Você não ganha nada separando os bancos de dados. Isso é puramente um problema 'humano' - para o servidor, são apenas bytes em um disco. Ele não se importa se seus 1 ou 100 bancos de dados. Mas se você dividir, precisará lidar com a sincronização de dados. Os problemas de indexação apresentados não são um problema real - você gastaria a mesma quantidade de tempo do processador mantendo os índices se os bancos de dados fossem divididos.

Se o desempenho começar a se tornar um problema, replicou o banco de dados para vários servidores para equilibrar as coisas.

Pode ou não valer a pena a troca na sua situação, mas manter a integridade dos dados é mais fácil com um único banco de dados. Pelo menos no MS SQL Server, você não pode chave estrangeira de um banco de dados para um banco de dados diferente. Você pode simular o comportamento de chave estrangeira com gatilhos, mas não é particularmente elegante.

Além disso, a criação de cópias locais dos dados pode ser perigosa quando as gravações entram em cena. Se o AppA e o AppB tiverem uma cópia de alguns dados compartilhados e o AppA os atualizar, o AppB ainda terá os dados antigos. Ou você precisará configurar gatilhos para manter os dados sincronizados.

Uma vez eu tive vários sites que se tornaram populares ao longo do tempo. Eles usaram bancos de dados separados, principalmente porque o provedor de hospedagem permitia apenas 1 GB de espaço de armazenamento cada. Mas! Assim que lancei um serviço que incluía todos esses sites, comecei a fazer transações entre esses sites, e a maneira mais conveniente de fazer isso é mover tudo definitivamente para um grande banco de dados.

Então, otimizei a estrutura do banco de dados e espremi as partes relevantes para esse banco de dados central, mas deixei todo o resto de fora.

Minha opinião está de alguma forma relacionada aos paradigmas da OOP. Dados semelhantes devem ser armazenados juntos; portanto, se você criar aplicativos diferentes, use bancos de dados diferentes para eles.

No caso acima, não foi possível evitar o uso de db comum, mas lembre-se de que também mantive algumas tabelas separadas em um db separado, que não fazem parte das consultas comuns.

Além disso, se você os mantiver separados, eles serão mais fáceis de fazer backup, haverá menos chances de perda de dados. Se algo der errado e os aplicativos interferirem um com o outro, o banco de dados fica bagunçado e você basicamente não deseja expor seu aplicativo a esse perigo.

Em suma, você pode manter um banco de dados comum para consultas comuns, mas também um para cada um de seus aplicativos.

Você pode elaborar mais sobre sua arquitetura de aplicativos?

Se o seu banco de dados funcionar apenas como um repositório de dados sem lógica do aplicativo, como gatilhos ou código do pacote de negócios, seria melhor ter um único banco de dados e encapsular a funcionalidade no nível de negócios aos serviços que usam o banco de dados para todas as suas ações. Se você tiver gatilhos ou código no esquema do banco de dados, terá grandes problemas usando um único banco de dados que pode ser problemático em muitos casos.