Dados e persistência

Oracle corporativo é a realidade da maior parte do que eu mantenho. Trabalhar bem nele, respeitando schema legado, transação e volume, determina mais o meu dia do que qualquer outra tecnologia da minha lista.

Onde cada um aparece

Oracle é o banco da maior parte do que eu toco, e é por isso que ele vem primeiro aqui. MongoDB entra onde o modelo não é relacional, PostgreSQL nos sistemas mais novos, e TimescaleDB aparece pouco, na série temporal de telemetria do monitoramento industrial.

No acesso, Entity Framework Core é o padrão, e Dapper entra onde a consulta precisa sair do ORM: relatório pesado, junção que o EF não resolve bem, procedure que já existia antes de mim.

Oracle, e por que ele vem primeiro

Currículo costuma listar banco de dados no fim, em ordem alfabética, como se fosse detalhe de implementação. No meu caso é o contrário: a maior restrição de projeto do parque é o Oracle corporativo compartilhado. O schema não é meu, a tabela que eu leio outro sistema também lê, e mudança de coluna precisa de combinação entre times.

O que isso exige na prática:

• Trabalhar em schema legado e compartilhado, respeitando quem mais depende dele
• Escrever consulta analítica com volume sem trazer a tabela para a memória da aplicação
• Ler plano de execução e corrigir consulta ruim
• Cuidar de transação que atravessa mais de uma tabela, com rollback correto
• Manter compatibilidade de banco durante migração de versão da aplicação
• Conviver com múltiplos schemas de domínios diferentes na mesma instância

EF Core e Dapper, no mesmo projeto

Escrita passa pelo ORM, porque ali o modelo de domínio manda na persistência: rastreamento de mudança, unidade de trabalho e transição de estado da entidade ganham do SQL escrito à mão. Leitura pesada passa por SQL direto, porque ali a consulta é o produto e precisa ser revisável linha a linha: relatório, painel, extração para conciliação, ou consulta que precisa de um recurso do Oracle que o ORM não expõe bem.

Ter os dois no mesmo projeto é escolher a ferramenta por caso, não por doutrina.

O que eu cuido no EF Core: consulta que gera N+1 sem avisar, rastreamento desligado no que é só leitura, migração de schema em base compartilhada onde nem sempre a aplicação pode alterar a tabela, e mapeamento de objeto de valor para coluna existente de schema legado.

MongoDB e PostgreSQL

São os bancos do que nasce agora, num parque onde o Oracle domina o legado.

MongoDB quando o documento é naturalmente sem esquema fixo: payload de integração que varia por parceiro, registro de log de processamento, dado cuja forma o fornecedor muda sem avisar. A armadilha que eu evito é usá-lo como banco relacional disfarçado, se a consulta precisa de junção, o dado estava no banco errado.

PostgreSQL quando o sistema é novo e não tem obrigação de conviver com o schema corporativo.

TimescaleDB, para série temporal

Extensão do PostgreSQL usada no Monitoramento industrial. Máquina em chão de fábrica emite evento continuamente, e guardar isso em tabela relacional comum funciona por algumas semanas antes de a consulta de painel começar a demorar: o volume cresce numa dimensão só, o tempo, e o índice tradicional não ajuda tanto quanto parece.

O que a extensão acrescenta, mantendo SQL e ferramental: hypertable com particionamento automático por tempo, política de retenção e agregação contínua. Foi o que permitiu o painel responder rápido sobre janela longa.

Onde apliquei

Pagamentos e antifraude · Monitoramento industrial · Comissionamento

Experiência · Reporte ao fabricante

O que eu ainda não fiz

Não sou DBA. Leio plano de execução e sei corrigir consulta ruim, mas tuning fino de instância, particionamento e replicação são território de outra pessoa. Não trabalhei com data warehouse próprio nem com pipeline de dados em escala analítica. Em TimescaleDB minha experiência é pouca e recente: sei modelar hypertable, retenção e agregação contínua, sem quilometragem de operação em escala.