Bancos de dados relacionais e desenvolvimento iterativo

Em muitas abordagens ao desenvolvimento de software, como metodologias ágeis, Design Orientado a Domínio e Análise e Design Orientado a Objetos, somos incentivados a adotar uma abordagem iterativa ao desenvolvimento.

Portanto, não devemos executar nosso modelo de domínio corretamente na primeira vez em que começarmos a trabalhar no projeto. Em vez disso, à medida que o tempo passa, refatoramos o modelo porque adquirimos uma compreensão mais profunda do domínio do problema com o tempo.

Além disso, mesmo se tentarmos antecipar um modelo perfeito, o que já estou convencido de que é muito difícil, os requisitos podem mudar. Então, depois que o software tenha sido implantado para produção, os usuários finais podem notar que uma certa exigência não foi completamente compreendido, ou pior, alguma exigência estava faltando.

O ponto aqui é que podemos acabar precisando alterar o modelo após a implantação do software. Se isso acontecer, temos um problema: o banco de dados de produção possui dados do usuário, o que é importante e já está ajustado no formato do modelo antigo .

Atualizar o código pode ser uma tarefa difícil se o código não for bem projetado e se o sistema for grande. Mas isso pode ser feito com o tempo, temos ferramentas como o Git que nos ajudam a fazer isso sem danificar a versão pronta para produção.

Por outro lado, se o modelo for alterado, se as propriedades das classes desaparecerem ou o que for, o banco de dados também deve ser alterado. Mas temos um problema: já existem dados que não podem ser perdidos, que já estão formatados para o modelo antigo.

Parece que um banco de dados relacional aqui está sendo uma barreira nos impedindo de desenvolver iterativamente e até atualizar o software quando exigido pelos usuários finais.

Uma abordagem que eu já usei foi codificar uma classe especial que mapeia tabelas de banco de dados antigas para novas. Portanto, essas classes selecionam dados no formato antigo, convertem-no para o formato usado pelo novo modelo e salvam nas novas tabelas.

Essa abordagem parece não ser a melhor. Minha pergunta aqui é: existem abordagens conhecidas e recomendadas para conciliar desenvolvimento iterativo com bancos de dados relacionais?

Ele não precisa ser de classes especiais, mas sim, você precisa de algo que pegue o banco de dados no formato anterior e o converta no atual.

A questão aqui é que você precisa desenvolver um processo para escrever e testar esses scripts e disciplina para nunca tocar os bancos de dados de teste e produção manualmente, mas sempre usando scripts de migração.

Toda vez que você precisa fazer uma alteração no banco de dados, escreve um script que o fará, seja em SQL ou usando sua camada ORM, e o compromete com o controle de versão, juntamente com as alterações que requerem o novo esquema. Então você tem algum script de controle que atualizará o banco de dados aplicando todos os scripts de migração que ainda não foram aplicados em uma sequência.

E certifique-se de modificar apenas os ambientes de desenvolvimento, teste e controle de qualidade compartilhados aplicando os scripts e revertendo para a versão anterior, se eles não funcionarem, para ter certeza de que eles funcionarão como planejado quando você os liberar na produção .

A nova instalação é feita simplesmente aplicando todos os scripts. Depois de um tempo, você poderá ter centenas deles e achar que é muito ineficiente, mas não caia na armadilha de tentar otimizá-lo. A instalação é uma atividade única e mantém trunfos confiáveis, tornando-o rápido.

O @Doc Brown já vinculou Martin Fowler: Evolutionary Database Design e /programming/334059/agile-development-and-database-changes , e eu adicionaria Alex Papadimoulis: Database Changes Done Right , que é mais curto e tem alguns exemplos.

Como um exemplo decente de ferramenta para implementar esse processo, sugiro Alambique . Ele é baseado na estrutura Python SQLAlchemy , mas você pode usá-lo com outras linguagens e estruturas se elas não tiverem seu próprio suporte à migração. A página da Wikipedia sobre Migração de esquema lista mais dessas ferramentas .

Curiosamente, esse é o mesmo problema enfrentado pela minha equipe de desenvolvimento atual. A pergunta contém várias sub-perguntas, portanto elas serão abordadas de forma independente.

Em primeiro lugar, um banco de dados relacional restringe demais o modelo de dados, dificultando muito as alterações?

Certamente , mas não necessariamente pelas razões citadas. Infelizmente, a versatilidade dos sistemas de gerenciamento de banco de dados relacional também leva à sua queda. O RDBMS foi desenvolvido originalmente para oferecer uma plataforma de armazenamento de dados relativamente simples que aceitaria grandes conjuntos de dados e os reduziria a um tamanho relativamente pequeno. Isso foi feito à custa da complexidade do modelo de dados e do poder de computação necessário. À medida que a complexidade do banco de dados aumentava, surgiram procedimentos, visualizações, funções e gatilhos armazenados para ajudar os administradores de banco de dados a lidar com a complexidade de maneira consistente e escalável.

Infelizmente, o modelo de banco de dados relacional não é orientado a objetos e, naturalmente, não é mapeado para entidades do mundo real como um modelo de dados. Isso nos leva à necessidade de ferramentas intermediárias, como mapeadores objeto-relacionais e similares. Infelizmente, embora essas ferramentas claramente tenham um lugar no mundo de desenvolvimento atual, seu uso é direcionado apenas a um sintoma do problema de complexidade de dados relacionais, e não à causa subjacente, que é um desalinhamento do modelo de dados para o mundo real.

Isso leva à segunda parte da pergunta, que era realmente mais uma suposição, mas deveria ser vista como uma pergunta: devemos executar nosso modelo de domínio corretamente da primeira vez?

Sim, até certo ponto. Como a pergunta apontou, raramente é possível entender completamente o problema quando iniciamos o processo de design. No entanto, a diferença entre um modelo de dados completamente incorreto, em oposição a um que pode ser aprimorado à medida que obtemos maior entendimento do domínio, é o modelo que mapeia coerentemente o mundo real. Isso significa que devemos fazer todos os esforços para criar um modelo de dados inicial que seja consistente com nossa compreensão do problema em termos de suas entidades do mundo real. Se começarmos a normalizar as entidades erradas, o modelo de dados estará errado de duas maneiras e a recuperação será difícil.

De várias maneiras, a mudança para soluções de banco de dados "No SQL" é resultado dos problemas de incoerência do modelo de dados. Utilizar uma abordagem No SQL orientada a objetos nos leva a pensar mais sobre o mapeamento entre nossos objetos no código e os do mundo real - e quando encontramos uma inconsistência, isso geralmente é evidente porque é inviável implementar em nosso base de dados. Isso leva a um melhor design geral.

Isso leva à pergunta final: um modelo de dados relacionais é inconsistente com a abordagem ágil?

Não, mas é necessária mais habilidade. Enquanto no mundo sem SQL, é trivial adicionar um campo ou converter uma propriedade em uma matriz, não é nada trivial fazer essas coisas no mundo relacional. É preciso, no mínimo, alguém capaz de entender o modelo de dados relacionais e as entidades do mundo real que eles representam. Essa pessoa é a pessoa que facilitará a atualização do modelo relacional à medida que a compreensão do modelo do mundo real for alterada. Não existe uma bala de prata para resolver este problema.

O ponto principal não é refatorar tanto que seu modelo muda além de qualquer reconhecimento. Mesmo com o desenvolvimento iterativo, você deve realmente construir sobre o material existente e não refatorá-lo em pedaços.

Isso fornece duas opções principais para lidar com grandes mudanças quando elas surgirem: a primeira é criar a camada de banco de dados como uma API, usar procedimentos armazenados para que eles possam ser alterados para se adequarem ao cliente sem alterar o esquema de dados subjacente.

A outra maneira é substituir as tabelas por um pouco de migração de dados. Quando uma alteração em grande escala é necessária, você cria o novo esquema e implementa um conjunto de scripts para levar os dados antigos e massageá-los para o novo formato. Custa tempo para fazer isso, e é por isso que você confia mais em métodos mais baratos de modificar o acesso aos dados (por exemplo, via SPs) como primeira opção.

Então: 1. tente pensar no futuro com design para não precisar mudar as coisas.

2. Confie em wrappers ou APIs para que as alterações sejam limitadas ou ocultas em um componente isolado

3. Reserve um tempo para atualizar corretamente, se necessário.

Essas etapas se aplicam a tudo, não apenas aos bancos de dados.