Como conciliar o OOAD e o Design de Banco de Dados?

5

Recentemente, estudei análise e design orientados a objetos e gostei muito disso. Em todos os lugares que eu li, as pessoas dizem que a idéia é começar com o conjunto mínimo de requisitos e melhorar ao longo do caminho, revisitando cada iteração e tornando-a melhor à medida que desenvolvemos continuamente e contatamos o cliente interessado no software. Em particular, um curso do Lynda.com disse muito: nós não queremos gastar muito tempo planejando tudo antecipadamente, nós só queremos ter o mínimo para começar e então melhorar cada iteração.

Agora, eu também vi um curso do mesmo cara sobre design de banco de dados, e lá ele diz de forma diferente. Ele diz que embora quando se trabalha com orientação a objetos ele goste da abordagem iterativa ágil, para o design de banco de dados deveríamos realmente gastar muito tempo planejando as coisas de antemão em vez de apenas seguir o caminho com o mínimo.

Mas isso me confunde um pouco. De fato, o banco de dados irá manter dados importantes de nosso modelo de domínio e talvez configurações do software e assim por diante. Agora, se eu vou revisitar continuamente a análise e o design do modelo, parece que o design do banco de dados também deve mudar. Da mesma forma, se planejarmos todo o banco de dados antecipadamente, parece que também estamos planejando todo o modelo, portanto, as duas ideias parecem ser incompatíveis.

Eu realmente gosto de abordagem iterativa ágil, mas também estou olhando para obter um melhor design para o banco de dados também, por isso, quando se trabalha com a abordagem iterativa ágil, como devemos lidar com o design do banco de dados?

    
por user1620696 31.10.2013 / 01:47
fonte

3 respostas

3

O problema com bancos de dados é que eles contêm dados. Isso significa que, se você quiser alterar a estrutura de um banco de dados, precisará lidar com todos os dados contidos nele, certificando-se de manter sua integridade do esquema original para o esquema revisado.

Isso nem sempre é fácil. Introduz riscos. A migração de dados entre alterações de esquema pode ser difícil de testar. Basicamente, bancos de dados podem ser desenvolvidos iterativamente, mas isso tende a ser uma dor na bunda.

O código, por outro lado, é muito mais fácil de alterar. Desde que você tenha testes no local, é razoavelmente direto determinar que o código refatorado ainda faz a mesma coisa que o original. Assim, a refatoração e o desenvolvimento iterativo funcionam bem no código do programa.

Não há uma resposta definitiva para reconciliar esses itens. Eu diria que o conselho que você recebeu é bom - tente minimizar o número de vezes que você reestruturou seu banco de dados. Isso não significa que você nunca pode mudar seu banco de dados, apenas não faça isso o tempo todo. Tente prever as alterações necessárias em várias iterações e atualize o esquema uma vez para cada 3 ou 10 iterações de codificação. Pense nas alterações do esquema do banco de dados como parte de suas principais versões, enquanto as alterações no código podem ser lançadas por ponto.

    
por 31.10.2013 / 05:54
fonte
2

O truque está na forma como você aborda a persistência dos dados no final do seu código. Eu gosto de manter iterar em todas as frentes.

Se você mantiver um bom modelo de banco de dados (eu gosto de fazer isso com o MySQL Workbench) e tiver uma solução sensata para persistência (eu gosto de usar JPA), então você pode mudar e reimplantar banco de dados e todo código relacionado com facilidade.

Infelizmente, a abordagem tradicional é parcial para obter todas as informações de modo a obter o modelo de dados completo pronto, gastando muito tempo antes que os protótipos de trabalho possam ser gravados.

Um meio termo é o seguinte: ter tantos formulários usados no processo que estão sendo automatizados quanto possível tenham sua persistência definida e iterar com o restante da estrutura da base de dados (visualizações, procedimentos armazenados e tabelas auxiliares).

    
por 31.10.2013 / 01:56
fonte
1

Eu entendo que você ficou confuso. Você não pode criar um modelo de dados completo quando iniciar apenas criando um conjunto mínimo de recursos em sua solução.

Uma boa abordagem é aplicar um bom design à estrutura de dados inicial. Se o seu design foi bom, todas as adições posteriores não exigirão um novo design da sua estrutura inicial (há algumas exceções!). Certifique-se de ler sobre Normalização do banco de dados

O que você perceberá em um processo de desenvolvimento de software iterativo é que a estrutura de dados crescerá com a quantidade de requisitos que você criou em seu software. Nas fases posteriores de um processo de desenvolvimento de software, a quantidade de alterações solicitadas diminui, portanto, mudanças na fonte de dados também são menos prováveis.

Quando uma grande mudança é iminente, há alguma mágica que você pode fazer para diminuir o redesign necessário. Por exemplo, você pode deixar um modelo de dados existente intacto e criar um mapeamento personalizado em uma camada abstrata de sua solução. A maioria dos ORMs de hoje são muito adequados para isso.

    
por 31.10.2013 / 09:57
fonte