Usando um banco de dados comum para o desenvolvimento colaborativo

Question

Algumas das pessoas no meu projeto parecem pensar que o uso de um banco de dados de desenvolvimento comum com todos conectando a ele é a melhor coisa. Eu acho que não é e cada desenvolvedor ter seu próprio banco de dados (com periódicos dumps de dados atualizados) é o melhor. Estou certo ou errado? Você já encontrou problemas em qualquer uma destas abordagens?

Answer 1

O espaço em disco e CPU deve ser bastante barato que cada desenvolvedor pode executar sua própria instância do banco de dados , com uma compilação automatizada sob controle de versão. Isso é necessário para permitir que desenvolvedores de ser ousado em hacking no banco de dados, de forma isolada a partir de pirataria concorrente qualquer outro desenvolvedor.

O ser ressalva, é claro, que todas as alterações que eles fazem a sua instância privada são inúteis para qualquer outra pessoa menos pode ser aplicado automaticamente durante o processo de construção. Então, é preciso haver uma política firme de que o código da aplicação não pode depender de qualquer estado de banco de dados, a menos que o estado é representado por , muda-testado unidade controlada de versão para o DDL .

Para um excelente guia sobre a teoria e prática de tratar a definição de banco de dados como uma outra parte do código do projeto e coordenar alterações e refatorações, consulte refatoração Databases:. Banco de Dados Evolutionary design por Scott W. Ambler e Pramod Sadalage

Answer 2

Eu gosto de ter minha própria cópia do banco de dados para o desenvolvimento, porque lhe dá a flexibilidade para rapidamente as coisas mudam sem se preocupar como isso vai impactar outros.

No entanto, se todos os desenvolvedores estão cortando em sua própria cópia do banco de dados, torna-se mais e mais difícil de trabalho fusão de todos juntos no final.

Eu acho que você pode obter o melhor dos dois mundos, permitindo que os desenvolvedores a trabalhar em uma cópia local durante o desenvolvimento do dia-a-dia, mas cada desenvolvedor provavelmente deve mesclar seu trabalho em uma cópia comum em uma base regular bonita. Escrevendo um monte de testes de unidade também ajuda.

Answer 3

Nós compartilhar um único banco de dados entre todo o nosso desenvolvedor (20-ímpar), mas temos que ter isso estruturado de forma que toda a gente tem os seus próprios quadros.

Você não necessidade um banco de dados separado por desenvolvedor se você estruturar o direito aplicação. Deve ser configurável qual banco de dados ou tabela-prefix ele usa de qualquer maneira para que você possa movê-lo facilmente entre instâncias (teste de unidade, teste de sistema, teste de aceitação, produção, recuperação de desastres e assim por diante).

A vantagem de usar um único banco de dados é que o custo de manutenção é amortizado. Você não tem os seus DBAs tentando lidar com um monte de bancos de dados (ou, se você é uma loja pequena DB, você não tem todos os desenvolvedores tentando manter seu próprio banco de dados quando eles estão melhor utilizada no desenvolvimento).

Answer 4

Ter um único ponto de falha não é uma coisa boa, não é?

Answer 5

Eu prefiro um único banco de dados, compartilhado. Mas é muito dependente da situação e os aplicativos que estão sendo desenvolvidos.

O que funciona para mim pode não funcionar para você. Vá com seu intestino.

Answer 6

(Opção de criar-drop)

Se você está trabalhando com Hibernate ou qualquer plataforma baseada em hibernação você pode configurar seu banco de dados a ser criado quando você iniciar o servidor. Isto é muito útil quando você está adicionando novos atributos às suas aulas. Se este for o caso, cada desenvolvedor deve ter sua própria cópia do DB.

Se você não está mudando a estrutura DB em tudo, então você pode usar um único DB compartilhada. Neste segundo caso não é uma obrigação. Eu prefiro ter meu próprio DB onde eu posso fazer o que quiser. Por outro lado lembre-se que algumas consultas podem levar muito tempo e isso vai afetar toda a sua equipa se você estiver compartilhando um DB.