Modelagem de Um Sistema Financeiro

22/08/2016

0

Olá a todos, preciso desenvolver um sistema financeiro e tenho algumas dúvidas quanto a modelagem, a principal dúvida é se utilizo apenas uma tabela chamada movimentação ou se divido tudo em duas tabelas(entrada e saida). Bom, no principio imaginei o sistema funcionando da seguinte forma: o usuário poderá cadastrar os lançamentos(que poderão ser receitas ou despesas baseados no plano de contas), além disso, no sistema eu também poderia cadastrar uma compra ou uma venda(a compra ao ser paga geraria uma despesa e a venda ao ser paga geraria uma receita) e além disso eu teria os abastecimentos dos veículos, que não posso tratar como uma outra compra qualquer, nessa situação eu teria a tabela de movimentos:

-movimento_id
-compra_id
-venda_id
-abastecimento_id
-centro_custo_id
-tipo_movimento( RECEITA ou DESPESA)
-data
-valor_previsto
-operacao(COMPRA, VENDA,ABASTECIMENTO)
-descricao
-fornecedor_id
-cliente_id
-forma_pagamento
-situacao_pagamento
-numero_parcelas
-desconto
-valor_pago

neste caso eu teria uma tabela não normalizada, mas seria mais fácil extrair os dados pois eu teria apenas uma tabela, entretanto, dependendo da situação, vou ter muitos campos nulos nesta tabela, não sei até quanto isso pode ser prejudicial ao BD, ou se afeta apenas na organização dos dados mesmo. Conversei com algumas pessoas que me sugeriram trabalhar desta forma com apenas uma tabela de movimentações, mas também conversei com pessoas que me sugeriram desmembrar esta tabela em duas:

======== Receita =========
-receita_id
-venda_id
-data
-valor_previsto
-centro_custo_id
-descricao
-cliente_id
-forma_pagamento
-situacao_pagamento
-numero_parcelas
-desconto
-valor_pago



======== Despesa =========
-despesa_id
-compra_id
-data
-valor_previsto
-centro_custo_id
-descricao
-cliente_id
-forma_pagamento
-situacao_pagamento
-numero_parcelas
-desconto
-valor_pago

Qual a melhor opção a seguir? um tabelão desnormalizado mas que seja fácil extrair informação ou com duas tabelas de receita e despesa?
Ricardo Pereira

Ricardo Pereira

Responder

Post mais votado

22/08/2016

Olá Ricardo!

Fazer muito desnormalizado pode gerar vários problemas depois na programação, por mais que pareça mais fácil no começo. Já fiz um sistema financeiro comercial seguindo algo parecido. Sugiro o seguinte:

* Concordo com a tabela movimentação, podendo cadastrar as receitas e despesas (usar um campo \"tipo\" para indicar do que se trata cada lançamento). Não colocaria os IDs de compra e venda nela, pra não misturar as coisas
* Faria mais uma tabela COMPRA_VENDA e COMPRA_VENDA_PARCELA (mestre/detalhe), para que cada compra/venda teria uma lista de parcelas (no mínimo uma e no máximo N parcelas)
* Quando uma parcela for paga, faz uma rotina para cadastrar uma movimentação na tabela de movimentação

Jones

Jones Granatyr

Jones Granatyr
Responder

Mais Posts

22/08/2016

Ricardo Pereira

Olá Jones, muito obrigado por responder, pode me tirar mais algumas dúvidas seguindo sua abordagem?

a) com esta tabela compra_venda eu ainda teria as tabelas de compra e venda, ou salvaria tanto a compra quanto a venda nesta tabela?

=====Compra_Venda=====
- (pk) compra_venda_id
- (fk) compra_id
- (fk) venda_id

b) na minha tabela de movimentação devo guardar a chave da compra_venda_parcela?

======Movimentacao ====
- (pk) movimentacao_id
- (fk) compra_venda_parcela_if
Responder

24/08/2016

Jones Granatyr

Olá!

a) Poderia fazer somente uma tabela COMPRA_VENDA, armazenando compras e vendas aqui (elas devem ter praticamente os mesmos campos). Não teria as chaves estrangeiras que você colocou acima

b) É melhor armazenar na tabela COMPRA_VENDA_PARCELA o ID da movimentação que foi gerada. Dessa forma a tabela de movimentação fica independente das compras/vendas

Jones
Responder

24/08/2016

Ricardo Pereira

Muito boas as sugestões, na sugestão b) eu também já tinha pensado nessa forma, fazer a tabela ter o id da movimentação. Novamente Obrigado!
Responder

Utilizamos cookies para fornecer uma melhor experiência para nossos usuários, consulte nossa política de privacidade.

Aceitar