Migração e Evolução de Banco de Dados

Faz um tempinho que não dou as caras por aqui, no entanto, achei interessante compartilhar com vocês um pequeno estudo que estou fazendo entre um tempinho e outro que estou tendo. Sempre curti modelagem de dados, e já aproveitei ótimas horas da minha vida elaborando diagramas de classes e DER. No entanto, é sempre custoso, principalmente para um desenvolver, a execução do que está no papel. Horas criando scripts SQL, entendendo as particularidades de cada banco de dados, e, dependendo do projeto, batendo cabeça com N bancos de dados diferentes, um para cada ambiente.

Calma, todo mundo sabe que existem inúmeras ferramentas responsáveis por cuidar da migração e evolução do banco de dados. E dentro do universo Java, o Liquibase possui um lugar de destaque. No entanto, o que é muito comum de se ver, o desenvolvedor utilizar o mesmo script SQL e salvando dentro de uma migration no projeto. Isso, por si só, é incrível. Ter nas mãos alguém que se responsabiliza de evoluir o teu banco com base nos seus scripts. Maravilha. Mas nem tudo são flores. 

Aqui, entra o tema central deste artigo. Recentemente me propus a criar um micro serviço capaz de evoluir independente do banco, abstraindo essa camada e assim removendo este vendor lock-in. Já sabia que facilmente o Liquibase utiliza XML, mas estudando um pouquinho da sua documentação, descobri que da pra utilizar também JSON e, eureca, YAML.

Meu olhos brilharam diante dessa possibilidade, e corri para minha IDE e construí uma pequena POC com essa ideia. Rodei um Docker com Postgres e comecei a brincadeira.

O trecho a seguir mostra como criar uma tabela chamada "escola" com as colunas: id, nome e inep. Sem a necessidade de nenhuma linha de SQL.

databaseChangeLog
- changeSet:
    id: create_table_escola-1650592472333
    author: ysmaelmarinho
    changes:
    - createTable:
        tableName:  escola  
        columns:
        - column:
            name: id
            type: bigint
        - column:
            name: nome
            type: varchar(500)
        - column:
            name: inep
            type: varchar(8)
        schemaName:  matricula 

E o resultado foi esse:

A evolução da tabela segue na mesma linha, elegância e beleza das extensões .yaml

databaseChangeLog
- changeSet:
    id: add_primary_key_on_escola-1650593981628
    author: ysmaelmarinho
    changes:
    - addPrimaryKey:
        clustered:  true  
        columnNames:  id  
        constraintName:  pk_escola  
        schemaName:  matricula  
        tableName:  escola  
        validate:  true:

Auto increment da primary key

databaseChangeLog
- changeSet:
    id: add_autoincrement_on_id_on_escola-1650595341785
    author: ysmaelmarinho
    changes:
    - addAutoIncrement:
        columnDataType: bigint
        columnName: id
        defaultOnNull: false
        generationType: ALWAYS
        incrementBy: 1
        schemaName: matricula
        startWith: 1
        tableName: escola   :

E o resultado final:

O legal disso tudo é que dá pra utilizar outros formatos de migration, como o XML, JSON, SQL...

Este artigo tem como finalidade apresentar a você, desenvolvedor, possibilidades de manter seu banco de dados sem se preocupar tanto com a gestão dos scripts. Convido você a conhecer um pouco mais do Liquibase e sinta-se à vontade para opinar e contribuir com o assunto. 

Grande abraço