Usamos cookies para medir audiência e melhorar sua experiência. Você pode aceitar ou recusar a qualquer momento. Veja sobre o iMasters.
Quando trabalhamos com sistemas legados, principalmente em .NET ou outros frameworks tradicionais, uma dúvida que sempre surge é sobre onde colocar a lógica de negócio mais complexa.
A maioria dos desenvolvedores tende a optar por manter a lógica no código, por questões de facilidade de manutenção e entendimento. Mas, na prática, trabalhar com lógica pesada no banco — usando stored procedures ou funções — também tem seus prós, como reduzir a quantidade de round-trips e aproveitar a performance do banco.
Segundo uma experiência recente, a decisão depende muito do contexto do projeto. Em sistemas onde a lógica é muito específica do negócio, ela acaba ficando mais fácil de gerir no código, além de facilitar testes unitários. Já em cenários com regras bem definidas e estáticas, colocar no banco pode ajudar na performance e na consistência dos dados. Sem esse critério, a solução pode parecer simples no começo e cara no suporte.
O que pesa na balança é o custo de manutenção: alterar uma lógica no banco exige cuidado redobrado, pois pode impactar outros processos. Além disso, a equipe precisa estar confortável com o uso de stored procedures.
Como vocês têm lidado com essa decisão nas suas equipes? Preferem centralizar na aplicação ou no banco? E quais critérios vocês usam para escolher uma abordagem? Por isso, o recorte precisa considerar manutenção, validação e caminho de volta. Esse contexto ajuda a separar ganho real de novidade difícil de sustentar. A decisão fica mais saudável quando o time consegue medir o impacto depois. Sem esse critério, a solução pode parecer simples no começo e cara no suporte. O valor aparece melhor quando operação, produto e engenharia olham para o mesmo risco.
No meu ponto de vista, uma combinação inteligente dos dois mundos, dependendo do caso, costuma ser o caminho mais pragmático. Esse contexto ajuda a separar ganho real de novidade difícil de sustentar. A decisão fica mais saudável quando o time consegue medir o impacto depois. Sem esse critério, a solução pode parecer simples no começo e cara no suporte. O valor aparece melhor quando operação, produto e engenharia olham para o mesmo risco. Por isso, o recorte precisa considerar manutenção, validação e caminho de volta. Esse contexto ajuda a separar ganho real de novidade difícil de sustentar.
Eu sempre prefiro manter a lógica no código, pq assim fica mais fácil de versionar e testar. Mas em sistemas muito pesados, às vezes a stored procedure ajuda a tirar carga do servidor de aplicação.
manda um ae no backend eu faço bastante lógica, mas quando a regra é fixa e precisa de performance, uso funções no banco.
pois é, o custo de alterar no banco pode ser uma dor de cabeça depois.
cara, concordo que pra DX é mais tranquilo fazer tudo no código, mas às vezes o banco consegue otimizar bem essas operações, especialmente em consultas pesadas. depende do caso mesmo.