[Dúvida] Back-End e Banco de Dados – Quem deve determinar o fluxo do projeto?

Olá pessoal. Há um certo tempo, tenho mantido uma base de dados que utilizo para armazenar informações e gerar relatórios à respeito do meu trabalho, só para contextualizar – sou professor de um curso de informática (acabo tendo que resolver quase todos os problemas relacionados à tecnologia) e toda semana preciso gerar um relatório a respeito da frequência dos alunos, um trabalho que seria feito "na mão" é rapidamente feito utilizando algumas queries em SQL; na época eu estava começando a estudar sobre Banco de Dados e ter criado uma base de dados foi muito útil para o meu aprendizado, trouxe agilidade e tranquilidade para o meu trabalho.

Visando facilitar a minha vida, estou pensando em criar um programinha simples (aka: CRUD) que rode de maneira local – a linguagem que me sinto confortável é o Java e para persistência de dados optei pelo SQLite por conta da sua simplicidade. No entanto, durante a criação das entidades peguei-me refletindo sobre a questão mencionada no título, eu devo programar "orientado" ao banco de dados ou o banco de dados que deve se adequar ao meu programa? Como posso prosseguir diante desse questionamento? Preciso voltar a fase de planejamentos?

manierohá 10 dias

Não há uma resposta definitiva, pode depender do projeto, do expertise da equipe, que ferramentas vai usar ou outros critérios.

É certo que todo sistema deveria começar pela estrutura de dados, e em muitos casos isso significa começar pelo banco de dados, seja no modelo físico ou no modelo lógico (algo que quase todo mundo ignora ou faz de outro jeito sem perceber). Mas hoje muita gente cria as estruturas de dados da aplicação e tenta encaixar o banco de dados nisso. Minha experiência é que isso tende a não dar bom resultado.

Mas ainda fica a questão de quem é mais importante para o projeto. Se não for possível determinar, eu iria pelo DB.

Por outro lado, em aplicações simples, e a maioria delas são simples, qualquer coisa funciona e fazer o mais simples costuma ser a melhor decisão. E por isso pensar demais sobre o problema pode ser um caso de overengineering.

S2

Farei algo que muitos pedem para aprender a programar corretamente, gratuitamente (não vendo nada, é retribuição na minha aposentadoria) (links aqui no perfil também).

Mutable8141há 10 dias
*overengineering* é um termo que eu não conhecia mas que talvez resuma bem o porquê dos meus projetos sempre ficarem presos no papel... obrigado pela sua resposta, foi bastante esclarecedora e me ajudou a refletir um pouco sobre essas decisões relacionadas ao projeto, no meu ver acredito que começar pelo banco de dados tende manter o projeto "organizado", já que estamos definindo de fato o que é importante ou não. futuramente compartilharei os resultados, abraços... S2
Oletroshá 10 dias

Meus 2 cents:

Uma dica que aprendi no inicio da carreira foi: quando for construir uma aplicacao, veja quais os relatorios (as saidas) que ela precisa gerar, mapeie os dados e parta dai.

OK, mantidas as proporcoes e devidas atualizacoes (afinal a dica eh dos anos 80) - sempre achei uma metodologia interessante: identificar primeiro no levantamento de dados quais as informacoes que de fato o usuario precisa para dai mapear a estrutura necessaria que o sistema devera ter.

Existe um monte de armadilhas aqui, como a possibilidade do usuario passar uma necessidade que eh apenas legada e nao real:

Entao: mapeamento de dados => BD => aplicacao.

Atualmente, nas experiencias de "vibe coding" com IA, tenho tentado o seguinte: criar um PRD descrevendo as tabelas e o que o sistema deve fazer e depois passar no replit/loveble/etc.

1. Exemplo de prompt "vibe coding" primeiro no chatGPT/deepseek/claude/quewn/etc:

Crie um PRD para o seguinte aplicativo:

Um app para atividade X: precisa ter uma landing page com botao de login. Apos o login devera abrir uma dashboard com menu vertical com as opcoes disponiveis.

O app precisa ter CRUD de users, roles e permission em tabelas separadas

O app precisa ter CRUD de XXX.

Descreva as tabelas e campos necessarios.

2. Com o PRD gerado acima, ai eh so passar no replit/lovavle/v0/etc e ver no que da

manierohá 10 dias
Eu gosto de muitas da suas respostas, mas vou discordar de parte desta. Embora pareça uma boa ideia, e eu já fiz muito isso, e não descarto como uma forma de fazer uma parte, tentar descobrir quais relatórios serão necessários para montar a estrutura de dados costuma dar errado, até porque semrpe surgirá nos relatórios, e a estrutura não pode mudar em função disso, ela tem que ser bem feita e relativamente estável para suportar os relatórios. Não quer dizer que não posso colocar novos dados, mas quem deve definir quais serão eles é o coração da aplicação, não a saída. Mais uma vez, eventualmente a saída pode ser usada como ideia básica para entender o que o sistema precisa. O que primeiro deve ser feito sempre é levantamento de requisitos. EM alguns casos os relatórios, provavelmente já existentes, podem ser parte da equação para achar os requisitos, mas ele deve ser feito de forma muito mais ampla. Levantar os dados corretamente é fundamental, e isso a maioria sdas pessoas não sabem fazer bem, eu mesmo sonhecendo as técnicas e muita experiência ainda falho nisso. Depois estruturar os dados baseando-se nos requisitos tem grande importância para o resto sair certo, e isso eu já sou bem melhor, ainda que não perfeito, mas vejo que muita gente não faz certo porque aprenderam fazer errado desde o início. O resto do sistema tem alguyma importância, claro, mas bem menor. E os relatõrios é quase algo burocrático. De fato o usuário não sabe o que ele precisa, e por isso é difícil levantar requisitos, até porque você não é o usuário, e por isso não se sabe bem quais relatórios são úteis. Vou me abster sobre Vibe Coding, já falei bastante sobre isso, ou eu sou burro demais ou...
Oletroshá 10 dias
Meus 2 cents extendidos: De boa, discordar nao eh um problema. Levantamento de requisitos eh quase trabalho de detetive (dr. house ?) - os usuarios mentem/omitem, as vezes mesmo sem intencao. Como precisamos de um ponto de partida - usar os relatorios/saidas que os usuarios utilizam no seu dia-a-dia pode ser uma opcao. E concordo contigo quando diz que o sistema nao pode ser apenas uma imagem dos relatorios - ate porque a burocracia muda (contabilidade/folha alguem ai ?). Quanto ao "Vibe Coding", longe de gostar dele - conseguir algo que preste no replit/v0/cursor/etc eh um exercicio de masoquismo e paciencia - eh algo que vejo como futuro inevitavel, por isso compartilho o que tenho experimentado. Como ja gastei muita sola de sapato em livrarias/bibliotecas e quetais - vejo a IA apenas como uma extensao disso: tinha gente que simplesmente copiava o codigo dos livros, tinha gente que procurava entende-los: isso nao mudou muito (hummm, talvez a facilidade e velocidade). Enfim, a ver como isso vai funcionar.
devmaykehá 10 dias

Vou falar da minha experiência. No início, quando eu estava aprendendo, me parecia muito mais natural programar orientado ao banco, tanto que eu começava pelo banco, era mais fácil pensar assim. Hoje em dia, depois de estudar mais, arquitetura limpa, arquitetura em camadas, etc, é o contrário. O banco, eu vejo apenas como uma tecnologia de persistência e acaba sendo uma das últimas coisas que faço no projeto. Antes disso, o código é todo orientado ao negócio, o famoso DDD. O core de tudo é o que o código faz, quais regras de negócio ele tem, quais validações, quais entidades(entidades de código, não de banco) fazem parte do negócio. O código funciona independentemente do banco. O banco apenas persiste e recupera os dados. Se amanhã, eu quiser deixar de usar um banco relacional pra usar um no-sql, eu simplesmente troco o adaptador do banco e uso outro, sem afetar o propósito da aplicação. O banco é apenas uma ferramenta, uma tecnologia de persistência. Mais do que isso até, a própria API, libs externas, infra, seu eu quiser eu troco por outra, eu troco sem grandes dificuldades. Toda a tecnologia que permeia o código, são mais detalhes de implementação do que algo que tenha a ver com que o código ou negócio, que é o principal.

E porque seria assim? O banco é "descartável", as coisas só estão ali porque a aplicação(quando tem uma aplicação), colocou. Poderia ser esse banco ou qualquer outro, as coisas, se fossem orientadas ao banco, seriam sempre diferentes. Mas o banco só serve pra persistir dados e nada mais. Já as regras de negócio da sua aplicação, elas só mudam se o negócio mudar, assim como o banco também deveria mudar. Por exemplo, você modela na aplicação que um usuário pra realizar determinada tarefa no seu site deveria ser maior de idade, isso é uma regra de negócio. Você então determina isso na aplicação, faz as validações implementando essa regra. Essa regra pertence ao domínio porque é uma ideia, uma regra de negócio, ela pertence ao "código" porque a regra é primária, ela não depende de como os dados são salvos. As restrções dos bancos devem servir apenas pra manter a normalização dos dados, aintegridade, a consistência dos dados, etc. Não interessa AO BANCO se um número tem que ser maior de "18 anos" ou não, aliás, o banco só trata um número, o conceito de restrição de IDADE, se trata de negócio/código.

Então se fosse pra ser curto e grosso, eu diria que o código é orientado ao negócio e vem antes de pensar sobre como os dados serão modelados ou salvos, o banco não é orientado a nada, só serve pra persistir. No seu caso, é como se o "código" estivesse na sua cabeça, você pensa que orientou algo aos dados, mas não, você orientou o banco à sua necessidade. O código faz isso, ele modela a sua necessidade, agora se é o banco A, B, com tecnologia X ou Y, se vai salvar na nuvem, na memória, no disco ou onde for, isso não interessa.

manierohá 9 dias
De fato não interessa o banco. Em parte. E você já fez essas coisas todas que diz aí? A minha experiÊncia de mais de 40 anos é que as pessoas acreditam nisso mesmo, mas elas não sabem na prática como é. E acaba acontecendo duas coisas: a) o sistema era tão simples que qualquer coisa serve e nunca haverá necessidade real de trocar nada, qualquer porcaria que a pessoa fizer vai dar conta, até tudo errado. b) o sistema precisa ser muito bem arquitetado para aguentar o traco, e na rara ocasião que precisará trocar o banco de dados especialmente, mas pode valer para outras coisas em menor grau, significa que já está ruim por ter criado camadas desnecessárias e não otmizadas para acessar o DB, a tal da arquitetura limpa é extremamente s uja, e justamente por ter feito isso é que pode ter surgido a necessidade de trocar algo. E se trocar não vai melhorar muito a não ser alguma questão pontual, e um dia vai aparecer questões novas que mostrará que a troca não foi perfeita. E para arrumar e deixar bom mesmo a silução será arracar essa camada que abstrai o banco de dados e usá-lo da forma correta a ser definida por um profissional competente nisso. Na ausência de alguém competente o que acaba acontecendo é a adoção de aruiteturas mais complexas ainda, por exemplo o uso de microsserviços para resolver um problema que nem deveria estar ali. Eu já dei consultoria que fizeram tudo isso para dar perfomance, e eu só mandei tirar, fazer o simples e a performance veio. Essencialmente nenhum caso precisa trocar de banco de dados, todos os mais conhecidos dão conta do recado nas mãos de quem sabe o que está fazendo, não importante o tamanho da bronca que está segurando. Até o SQLite, agora com tecnologias prontas pode dar conta em grande parte dos cenários (ele já dava no básico em muitos deles, pra quem sabia usá-lo). O banco de dados é só uma forma de armazenamento quando está atrás de uma aplicação. Tem usos diretos que é diferente. Mas não quer dizer que ele não deva ser otimizado. Uma boa estrutura resiste a mudanças de negócios mais facilmente, se o banco for modelado pensando no que o negócio precisa dá muito mais trabalho, e foge da ideia de que ele é só um meio de armazenamento. Ele deve se preocupar em armazenar bem, não modelar o negócio bem. Quem tem que modelar o negócio é a aplicação. Todas essas técnicas "modernas" como DDD, CA , etc., tem lá seu valor e cabe em alguns cenários, mas as pessoas precisam estar cientes dos custos que isso tráz, e quase ninguém analisa isso, usa porque "todo mundo" está usando (segredo: só uma minoria está usando mas só bem vocais), ou seja, apesar da ferramenta ter algum valor, a forma como se decide usar é modinha, é "boa prática" 9que está virando um vídeo no meu canal que estreará em breve e texto no meu blog, porque provavelmente é problema mais grave e frequente que se comete e "ninguém" fala dele. S2 --- Farei algo que muitos pedem para aprender a programar corretamente, **gratuitamente** (não vendo nada, é retribuição na minha aposentadoria) ([links aqui](https://github.com/maniero/SOpt) no perfil também).
devmaykehá 9 dias
Sim, coloco em prática tudo o que aprendi em produção e desde então, me facilitou demais problemas com bugs e manutenção, principalmente porque vários dos problemas críticos que podem acontecer na aplicação estão garantidos pelos testes. A ideia de mudar o banco é meramente ilustrativa, e me serviu de exemplo pra dar o tom do que é mais importante na aplicação, em um projeto que começa do zero. Ou você vai me dizer que o principal é o banco e o código, e negócio, é secundário? É claro, que raramente se precisa mudar. O ponto todo é que não tem porquê, de forma alguma, acoplar o banco a troco de nada, a troco de não usar um simples pattern de repository ou adapter na aplicação, que implicaria em uma arquivo de interface e uma injeção de dependência, onde em uma tarefa rotineira, não implica em muito mais trabalho e não diminui em nada a performance... não que você ou alguém em experiência de uso notaria. Eu olho pra um projeto "clean code" e sei onde as coisas estão, pode haver diferenças aqui e ali, mas mesmo essas mudanças são padrões. Se levarmos o princípio da menor surpresa em consideração, o que parece complexo pra quem não conhece, se torna muito comum e fácil de entender pra quem conhece. O complicado mesmo é o "simples" que pode ser feito de muitas maneiras diferente, e como ninguém segue padrão nenhum, cada um faz do seu próprio jeito. Nos outros casos, na gisgantesca maioria das vezes, é como você falou, claro que ninguém precisa usar microserviços. Isso é uma coisa que não se usa atoa. Mas em um time onde todo mundo conhece, seja "clean code", mvc, ou qualquer arquitetura em camadas que seja de conhecimento comum, não acredito que isso aumente a complexidade. Patterns, são repetitivos, as pessoas olham e inituitivamente reconhecem as coisas. Garanto pra ti que o mundo do software sofre muito mais por código bagunçado onde cada um faz do seu jeito "simples", feito de qualquer maneira, do que pela tal do over enginering. E todo projeto tem sua particularidade. Um projeto menor, não precisa ser implementado à risca o clean code. A questão das camadas é algo muito simples de se implementar. Por mais simnples que seja o sistema, colocar tudo dentro do controller achando que as coisas vão ficar mais simples ou mais rápidas, não vai resolver. Se você apenas separasse o seu caso de uso/service do controller e chamasse as operações de banco de outro de outro arquivo, injetando as dependências, essa simples separação já te colocaria em 70% do que é a clean arch. E foi feito o básico do básico na sua aplicação, sem comprometer em nada a legibilidade, a complexidade do seu projeto. Complexo é analizar um arquivo com 800 linhas.... Parece que o clean code é muito complexo na teoria, mas na prática é bem simples. Tem coisas que, seguindo boas práticas óbvias de desenvolvimento como o SOLID por exemplo, intuitivamente, o código fica "limpo". Não é uma questão de nomear pastas e arquivos, é onde as coisas devem ficar. Já viu um programador experiente, amontoar responsabilidades e acoplar funcionalidades em prol de "simplicidade" no código? Isso não existe, naturalmente, a sua aplicação vai ter camadas e em casos que você não quer acoplar uma lib externa, de repente um banco porque talvez você não confia, na verdade, não que você não confie no banco, mas talvez você não confie na estabilidade do ORM que você utiliza pra acessar o banco... seja qual for o motivo, esse tipo de desacoplamento é básico pra qualquer programador experiente. Não tem nada de complexo, trabalhoso demais ou mais lento em implementar isso. A gente tem um monte de termos e nomes técnicos e bonitinhos pra falar de código, e que virou modinha, mas a verdade é que programadores experientes fazem isso a anos sem dar nomes aos bois. Ou o código está todo em seu devido lugar, não misturando muitas responabilidades, não muito acomplado, não se repetinfo muito, ou, o código está todo feito de qualquer jeito sem se preocupar com nada. Não tem muito pra onde correr, você pode odiar o termo, a modinha, mas a ideia toda, no núcleo, está correta. Talvez não esteja correta nos detalhes, mas essencialmenbte, falar mal de clean code, ao meu ver é insanidade.
kriubahá 10 dias

Cara, em sistemas robutos/corporativos, eu evitaria colocar qualquer tipo de trigger, stored procedure, etc no banco de dados. Pra mim tudo o que pode ser feito através da aplicação, deve ser feito através da aplicação.

Dito isso, se a sua dúvida é sobre alterar o esquema do banco de dados pra facilitar seu desenvolvimento, não vejo necessidade nisso, basta mapear os dados - os famosos DTOs (ou utilizar um ORM/Micro ORM). Acho que isso vai contribuir mais com o seu aprendizado.

Mas pelo que entendi, o projeto é pessoal e somente você vai utilizar o sistema. Então, meio que não importa, basta que funcione, rs.

Oletroshá 10 dias
Meus 2 cents: So comentando como as coisas mudam - quando tirei certificacao como DBA (oracle) nos anos 90 a diretriz era clara: sempre que possivel usar triggers e stored procedures de forma a otimizar o processamento e centralizar as regras de negocio. Fazia sentido pois as aplicacoes dificilmente mudavam de banco: voce escolhia um e morria abracado nele. Aplicacoes onde pudesse escolher o banco nao eram tao comuns (noves fora os SQL as vezes eram bem otimizados por banco, principalmente nos JOINS e subqueries) Mas aos poucos isso mudou: o surgimento de bancos midirange (como o Interbase/Delphi) e a ascencao do desenvolvimento web (MySQL, PostgreSQL) alem da mudanca de alguns paradigmas (como o client/server onde o server poderia ser multicamada/multiplataforma) foram empurrando algumas destas "certezas" (como triggers e SP) para um campo cinza. Ainda vejo com bons olhos certas otimizacoes sendo feitas em banco (principalmente em aplicacoes mais robustas) - mas entendo que aplicacoes mais simples isso ja nao eh tao relevante. Certas coisas me doem (como ver PK com uuid/cuid) mas enfim - eh um outro momento.