Deve-se usar um banco de dados separado para dados do aplicativo e dados do usuário?

5

Estou trabalhando em um projeto há algum tempo e não tenho certeza de qual é a melhor arquitetura. Estou interessado no consenso. A resposta para mim parece bastante óbvia, mas algo sobre isso está cavando em mim e eu não posso escolher o que.

O TL; DR é: como você lida com um programa com dados do aplicativo e dados do usuário no mesmo banco de dados que precisa receber atualizações periódicas dos dados do aplicativo? Um banco de dados para dados do usuário e um para o aplicativo, ou ambos em um?

A versão detalhada é ... se um aplicativo tiver um banco de dados que precise manter os dados do aplicativo E os dados do usuário e os dados do usuário referirem-se aos dados do aplicativo, será mais natural armazená-los no mesmo banco de dados.

Mas, se houver necessidade de atualizar os dados do aplicativo dentro desse banco de dados periodicamente, isso deve ser removido em dois bancos de dados para que seja possível fazer o download do arquivo de banco de dados do aplicativo atualizado como uma atualização e substituir o antigo? Ou eles devem permanecer como um banco de dados, e os dados do aplicativo devem ser atualizados por meio de um script que insira os novos dados no banco de dados existente? O segundo parece claramente preferível para mim ... mas, por algum motivo, não parece certo, e não consigo entender por quê.

    
por trycatch 20.03.2012 / 02:57
fonte

3 respostas

4

Se você precisar mover o aplicativo, independentemente do banco de dados do usuário, precisará de um banco de dados separado para o aplicativo (em qualquer formato), para que o banco de dados possa viajar com o aplicativo, deixando os dados do usuário intactos em sua localização original.

Portanto, se o banco de dados do aplicativo for atualizado periodicamente do fornecedor (você), ele deverá ser mantido separado do banco de dados do usuário, para que você possa distribuir as alterações no banco de dados do aplicativo sem afetar o banco de dados do usuário. .

Agora, se você precisar adicionar campos ou tabelas ao banco de dados do usuário, essa é uma história diferente. Para isso, você precisa de um módulo que possa aceitar como entrada uma tabela de mudanças do banco de dados do aplicativo, para ser aplicada ao banco de dados do usuário. Alguns programas fazem isso "convertendo" o banco de dados do usuário para o novo formato.

A conversão de dados pode ser feita usando o SQL DDL para aplicar as atualizações de campo e tabela ao banco de dados do usuário, de forma que não afete negativamente os dados do usuário. Em alguns cenários avançados, as transformações de dados podem realmente ocorrer; normalização ou desnormalização, por exemplo.

Se você precisar fornecer aos usuários a capacidade de fazer uma transferência de dados, use outro mecanismo, como um canal de comunicação ou um arquivo de importação / exportação contendo os dados a serem transferidos (talvez em XML).

    
por 20.03.2012 / 04:41
fonte
3

Eu não acho que isso realmente importe. Exceto outros requisitos, contanto que você possa atualizar os dados do aplicativo conforme necessário, seja em um banco de dados separado ou o mesmo não pareça muito pertinente. Scripts SQL podem eliminar / recarregar tabelas em qualquer caso.

    
por 20.03.2012 / 04:57
fonte
2

Eu olharia o acoplamento. Todos os seus dados estão juntos, ou seja, todos os dados estão no mesmo contexto limitado (para usar a terminologia de design orientada por domínio)? Se não, então você pode querer dividi-lo.

Para uma aplicação, a localização física não importa tanto quanto a lógica, mas para manutenção / desempenho, o físico é bastante importante.

O fato de isso incomodar você em algum nível significa que a estrutura pode não ser confortável. Analise as relações entre os dados mais de perto e faça uma chamada.

    
por 20.03.2012 / 05:08
fonte