Banco de dados por aplicativo versus um grande banco de dados para todos os aplicativos [fechado

https://stackoverflow.com/questions/2804452

25-09-2019
|

Pergunta

Estou projetando alguns aplicativos que compartilharão 2 ou 3 tabelas de banco de dados e todas as outras tabelas serão independentes de cada aplicativo. Os bancos de dados compartilhados contêm principalmente informações do usuário, e pode ocorrer o caso em que outras tabelas precisam ser compartilhadas, mas esse é o meu instinto falando.

Estou inclinado sobre o único banco de dados para todas as soluções de aplicativos, porque quero ter integridade referencial e não precisarei manter as mesmas informações atualizadas em cada um dos bancos de dados, mas provavelmente vou terminar com um Banco de dados de mais de 100 tabelas, onde apenas grupos de dez tabelas terão informações relacionadas.

O banco de dados por abordagem de aplicativo me ajuda a manter tudo mais organizado, mas não sei uma maneira de manter as tabelas relacionadas em todos os bancos de dados atualizados.

Então, a pergunta básica é: qual das duas abordagens você recomenda?

Obrigado,

Jorge Vargas.

Editar 1:

Quando falo sobre não ser capaz de ter integridade referencial, é porque não há como ter chaves estrangeiras nas tabelas quando essas tabelas estiverem em diferentes bancos de dados, e pelo menos uma das tabelas por aplicativo precisará de uma chave estrangeira para um dos compartilhados mesas.

Editar 2:

Links para questões relacionadas:

Somente o segundo tem uma resposta aceita. Ainda não decidi o que fazer.

Responda:

Decidi ir com um banco de dados por aplicativo com referências de dados cruzados a um banco de dados compartilhado, adicionando visualizações a cada banco de dados imitando as tabelas no banco de dados compartilhado e usando o Nibernate como meu ORM. Como sistema de associação, usarei o ASP.NET ONE.

Também usarei gatilhos e exclusão lógica para tentar manter no mínimo o número de identificações que estarei voando em torno de Livin 'La Vida Loca sem os pais. O esforço de desenvolvimento necessário para manter os bancos de dados é sincronizado é demais e a recompensa é muito pouco (como todos apontaram). Então, prefiro lutar pelo meu caminho através de registros órfãos.

Como o uso de um ORM e as visualizações foi sugerido pela primeira vez pelo Svinto, ele obtém a resposta correta.

Obrigado a todos por me ajudar com essa decisão difícil.

Solução

Depende e suas opções são um pouco diferentes, dependendo do banco de dados e das estruturas que você está usando. Eu recomendo usar algum tipo de ORM e assim você não precisa se incomodar muito. De qualquer forma, você provavelmente poderia colocar cada aplicativo em seu próprio esquema no banco de dados e, em seguida, referenciar as tabelas compartilhadas por schemaname.tablename ou criar visualizações em cada esquema de aplicativo que é apenas um SELECT * FROM schemaname.tablename e depois codifique contra essa visão.

Outras dicas

Nenhuma forma parece ideal

Eu acho que você deve considerar não fazer referências na camada de banco de dados para relações entre aplicativos e torná-las na camada de aplicativos. Isso permitiria que você o dividisse em um banco de dados por aplicativo.

Estou trabalhando em um aplicativo com mais de 100 tabelas. Eu os tenho em um banco de dados e são separados por prefixos - cada tabela tem prefixo para o módulo a que pertence. Em seguida, eu criei uma camada sobre as funções do banco de dados para usar esses grupos personalizados. Também estou construindo administrador de dados, que aproveita esses grupos de tabela e facilita muito a edição de dados.

Não há regras difíceis e rápidas para escolher uma em detrimento da outra.

Vários bancos de dados fornecem modularidade. No que diz respeito à sincronização em vários bancos de dados, pode-se usar o conceito de servidores vinculados e suas visualizações e também pode obter as vantagens do banco de dados integrado (acesso unificado).

Além disso, manter vários bancos de dados pode ajudar a um melhor gerenciamento de segurança, dados, backup e restauração, replicação, escala etc.

Meus 2 centavos.

Isso não parece "muitos aplicativos", mas como "um sistema de aplicativos com diferentes executáveis". Naturalmente, eles podem compartilhar um banco de dados. Faça o uso inteligente de esquemas para isolar as diferentes áreas funcacionais em um banco de dados.

Um banco de dados para todo o aplicativo, na minha opinião.

Com a outra abordagem, você acabaria se replicando e, na minha opinião

A abordagem mais apropriada do ponto de vista da escalabilidade e manutenção seria tornar o subconjunto de tabelas "compartilhado/comum" e colocá-lo no banco de dados "Commons", para todos os outros têm 1 dB por aplicação por escopo lógico (lógica de negócios determinado) e manter essa estrutura sempre

Isso aliviará os procedimentos de comissionamento/descomissionamento/realocação/manutenção do seu software (você saberá exatamente qual DBS afetado (Commons+App_Specific) está envolvido se você souber qual aplicativo você vai tocar e vice -versa.

Em nossos negócios, seguimos um banco de dados separado por aplicativo, com referências de banco de dados cruzados para a pequena quantidade de informações compartilhadas e um servidor vinculado ocasional. Isso funcionou muito bem com ambientes de desenvolvimento, encenação, construção e produção.

Para os usuários, toda a nossa base de usuários está no Windows. Usamos o Active Directory para gerenciar os usuários com referências de aplicativos a grupos, para que os aplicativos não precisem gerenciar usuários, o que é bom. Não centralizamos o gerenciamento do grupo, ou seja, cada aplicativo possui tabelas para grupos e segurança que não são tão agradáveis, mas funciona.

Eu recomendaria que, se seus aplicativos forem realmente diferentes, para ter um banco de dados por aplicativo. Olhando para trás, o banco de dados compartilhado central para os usuários também parece viável.

Você pode usar gatilhos para integridade referencial de banco de dados cruzado:

Crie um servidor vinculado para o servidor que contém o banco de dados que você deseja fazer referência. Em seguida, use a nomeação em 4 partes para fazer referência à tabela no banco de dados remoto que contém os dados de referência. Em seguida, coloque isso na inserção e atualize gatilhos na mesa.

Exemplo (assume inserções e atualizações de linha única):

DECLARE @ref (datatype appropriate to your field)

SELECT @ref = refField FROM inserted

IF NOT EXISTS (SELECT *
FROM referenceserver.refDB.dbo.refTable
WHERE refField = @ref)
BEGIN
RAISERROR(...)
ROLLBACK TRAN
END

Para fazer inserções e atualizações de várias fileiras, você pode entrar nas tabelas no campo de referência, mas pode ser muito lento.

Eu acho que a resposta para esta pergunta depende inteiramente de seus requisitos não funcionais. Se você estiver projetando um aplicativo que um dia precisará ser implantado entre os 100 dos nós, precisará projetar seu banco de dados para que, se necessário, possa ser escalado horizontalmente. Se, por outro lado, esse aplicativo for usado por uma mão cheia de usuários e pode ter uma vida útil curta, você será diferente. Eu ouvi recentemente um elenco de pod de como a arquitetura do eBay é configurada, http://www.se-radio.net/podcast/2008-09/episode-109-ebay039s-architecture-rinciples-randy-shoup, e eles têm um banco de dados por fluxo de aplicativos e usam sharding para dividir as tabelas nos nós físicos. Agora, seus requisitos não funcionais são que o sistema está disponível 24/7, é rápido, pode suportar milhares de usuários e isso não perde dados importantes. O eBay faz milhões de libras e, portanto, pode apoiar o esforço que isso leva para desenvolver e manter.

De qualquer forma, isso não responde à sua pergunta :) minha opinião de pessoal seria garantir que seus requisitos não funcionais tenham sido documentados e assinados por alguém. Dessa forma, você pode decidir sobre a melhor arquitetura. Eu ficaria tentado a ter cada aplicativo usando seu próprio banco de dados e um banco de dados central para dados compartilhados. E eu tentaria minimizar as dependências entre eles, o que tenho certeza que não é fácil ou você teria feito isso :), mas eu também tentaria evitar ter que produzir algum tipo de software de louça para manter as tabelas em Sincronize, pois isso pode criar dores de cabeça para você.

No final do dia, você precisa colocar seu sistema em funcionamento e os caras com o cabelo pontudos não dão a mínima para o quão legal é o seu design.

Fomos para dividir o banco de dados e ter um banco de dados comum para todas as tabelas compartilhadas. Devido ao fato de todos estarem na instância do SAVE SQL Server, não afetou o custo da execução de consultas em vários bancos de dados.

A chave na replicação para nós foi que o servidor inteiro estava em uma máquina virtual (VM); portanto, para a replicação criar ambientes de dev/teste, o suporte de TI criaria apenas uma cópia dessa imagem e restauraria cópias adicionais quando necessário.

Licenciado em: CC-BY-SA com atribuição

Não afiliado a StackOverflow