base de dados - sistema financeiro

799 views
Skip to first unread message

Pedro Ivo B. Gimenes

unread,
Mar 13, 2009, 10:58:01 AM3/13/09
to GOPHP
senhores (e senhoritas)

pra melhor focar nossas discussoes abro essa thread pra discutirmos a
modelagem do banco.
em anexo meu primeiro desenho e a planilha das minhas finanças esse ano.

quem tiver planilhas e puder enviar seria bom ver a forma como
organizam seus dados pra termos melhores idéias.
proponho que as alterações e sugestões no modelo sejam feitas
visualmente com os comentarios na imagem e documentadas no email.

como já expliquei muito do que desenhei ai, me redimo por nao escrever
tudo aqui de novo.

ps: nao riam, eu nao tenho afinidade dom excel, e sim, eu gosto de
cerveja e nao ganho tudo aqui lá. x)

abraços.

--
Pedro Ivo Branquinho Gimenes
"音乐可以结束,生命可以结束,理想不会"

financas.JPG
despesas 2009.xls

Pedro Ivo B. Gimenes

unread,
Mar 13, 2009, 11:23:15 AM3/13/09
to GOPHP
se entendi bem o id_produto eh null ou 0 por padrão e não notnull, já
que pode ou não ser preenchido, certo?
isso.. desculpa.. pode ser nulo...

Nessa modelagem, só movimentações do tipo compra envolveriam produtos, certo?
exacto, da mesma forma que só movimentações de pagamento, saques,
transferencias envolvem contas.

É realmente necessário o campo valor_efetivo_total, jah que temos o
quantidade e o valor_unidade?
esse valor é por exemplo: vc ganhou um desconto no final, o tiozinho
da feira arredonda o valor total em alguns euros (ou reais).
ou então num saque,  vc nao precisa colocar um valor_unidade. a minha
ideia desse campo é que a trigger avalia ele.
se num insert ou update, ela verifica se tem valor nesse campo e faz o
calculo pra atualizar a tabela de contas (campo saldo)

A tabela movimentos não precisaria de ter um campo descrição?
realmente não tem... mas acho mais interessante um campo pra
observaçoes, pois a escrição ja é o tipo do movimento, marca,
produto.......

E se desmembrássemos os lançamentos futuros em uma outra tabela e eles
serem um tipo de movimento?
Tabela futuros:
- id_futuro
- id_movimento
- data_prevista
- valor_previsto
tb pensei nisso, entretanto acho que a efetivação desse movimento vai
demandar demasiado esforço (alteração de flag desta tabela, associação
de codigo do movimento com essa tabela, criação de um novo registro de
movimento......) sendo que no final todos são movimentos...
é uma colocar um tipo de movimento: lançamento futuro...

fiz isso ai no erwin, nao tem jeito de exportar isso, fica ai a ideia
pra já ter uma base pra edição disso, exite alguma ferramenta web? pra
criação de modelo de dados?
quando chegar em casa posso exportar o script do banco (oracle).

lembrando.. a ideia eh fazer algo rapido, simples e funcional agora,
já pensando no futuro....
perguntas a se fazer:
no futuro, ao se remodelas, pode ser complicada a migração dos dados?
tem dados desnecessários que vão ser eliminados no futuro?
se eu dividir essa tabela, é facil fazer a adaptação dos dados?
se eu unir mais tabelas, o processo continua simples?
ganho em performace?
aumenta a complexidade das consultas?
quais e que tipo de relatorios vou querer?


2009/3/13 Pedro Ivo B. Gimenes <lista...@gmail.com>:

Pedro Ivo B. Gimenes

unread,
Mar 17, 2009, 10:45:22 AM3/17/09
to GOPHP
mais idéias? criticas? sugestões? exemplos? perguntas?

Walker de Alencar

unread,
Mar 17, 2009, 5:00:00 PM3/17/09
to go...@googlegroups.com
Quanto a ferramenta há como usar vários, gosto do DBDesign e do MySql Workbench, tenho testado o TOAD for MySQL.

O bacana do TOAD é que ele possui versoes para vários bancos, e facilita migrar um MER por exemplo.


2009/3/17 Pedro Ivo B. Gimenes <lista...@gmail.com>



--
Walker de Alencar
Arquiteto Web/PHP
http://www.walkeralencar.com
(62) 8172-5487

Pedro Ivo B. Gimenes

unread,
Mar 17, 2009, 8:12:29 PM3/17/09
to go...@googlegroups.com
Vi os screenshot do kmymoney e vi uma coisa interessante..
tem que dar pra colocar despesas futuras ciclicas..

tipo.. aluguel, é todo mes... do jeito que ta o modelo da pra colocar tipo, 12 meses, ai a ideia seria inserir 12 registros...

ou somente 1 registro com a informação de mensal seria melhor? como seria a efectivação desses movimentos? e se na hora de pagar vc teve que pagar mais ou menos?

abraços

2009/3/17 Walker de Alencar <walker...@gmail.com>
Reply all
Reply to author
Forward
0 new messages