Executando verificação de segurança...
1

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.

Carregando publicação patrocinada...
2

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.