Não se Deve Utilizar os Recursos Extras de um SGBD em um Sistema?

3 respostas
programaçãosql
I

Pessoal, bom dia. Ultimamente me deparei com a necessidade de atualizar todos os registros de uma determinada tabela A a partir de uma data específica, em relação à inclusão, atualização ou exclusão de um registro em uma outra tabela B. Explico:
Eu tenho uma tabela denominada FluxosCaixa que registra todas as Movimentacoes, ou seja, entradas e saídas de dinheiro do caixa. Logo, toda vez que um valor é cadastrado em movimentações, o sistema deve saber se é uma receita ou um gasto. Se for gasto, se é um custo ou uma despesa. A questão é que o sistema deve permitir que se faça lançamentos futuros, as chamadas previsões. Por exemplo, O fluxo de caixa 1 é referente ao mês 5. Deve ser possível abrir outros fluxos de caixa para os meses seguintes para que se possa lançar movimentações previstas, como por exemplo, para entrada em 60, 90 dias, etc. Então, se há uma movimentação para o fluxo de caixa, por exemplo, 3, então quando se movimenta algo para o fluxo de caixa 1, devo atualizar todos os fluxos de caixa seguintes, porque cada um deles baseia o seu saldo inicial pelo saldo final do fluxo de caixa anterior:

Eu implementei uma trigger para resolver essa questão, mas daí eu me lembrei que um de meus professores havia dito nos tempos de graduação que é mais fácil um sistema mudar de SGBD do que de linguagem, então não se deve usar os recursos ‘extras’ do banco. No caso, de um SGBD para outro a forma de implementar a trigger pode mudar, então é melhor não deixar sob responsabilidade de uma trigger a resolução da questão. Vocês concordam? Alguém já passou por um problema semelhante a esse?

Obs.: eu sei que armazenar dados calculados no banco vão contra a 3FN, mas eu implementei assim para facilitar a minha vida nos testes da trigger. Na versão final, as colunas saldo_corrente e saldo_final não constarão.

3 Respostas

javaflex

Isso é papo acadêmico. Profissionalmente o que vi na prática foi o contrário, mudar “linguagem” e banco continuar o mesmo.

Eu sempre uso o máximo do banco para melhor performance e praticidade. Se realmente for o melhor no seu caso, nao se limite a sua aplicação.

Jonathan_Medeiros

Se o sistema já possuí regras e tratativas implementadas no banco de dados, não vejo nenhum problema!
Agora se atualmente não existe nada do tipo na base de dados começar a fazer isso começa a deixar o sistema totalmente dependente do banco de dados.

A premissa é sempre resolver um “problema” existente, atualmente eu tenho preferência por não usar os recursos do banco de dados, mas essa é uma escolha minha, já trabalhei em lugares que faziam uso de recursos na própria base de dados também.
Único problema que vejo é que se isso não for muito bem documentado, acaba ficando difícil dar manutenção com o passar do tempo, pois o comportamento do sistema acaba sendo dividido com o banco de dados.

Lucas_Camara

Nesse seu caso, o argumento do professor tah meio viajado. Acho mais fácil mudar o sistema (linguagem) do que o banco de dados dependendo do cenário.

Não curto de ficar metendo lógica negocial em recursos de banco (como trigger, view, procedures, etc.). Somente se for para resolver coisas pontuais.

Criado 28 de maio de 2020
Ultima resposta 28 de mai. de 2020
Respostas 3
Participantes 4