[firebase-br] RES: Dúvida com controle de estoque

Marcelo - MK Softwares marcelo em mksoftwares.com.br
Sex Jul 28 09:44:40 -03 2017


Ola Adilson

Muito obrigado por compartilhar a sua experiencia comigo/conosco. Mas acabei ficando com uma duvida. Hoje em um relatório de posição de estoque o sistema de gestão utiliza uma query mais ou menos assim:
Select codpro, descpro, precocusto, ..., estoqueatual from produtos blablabla

No seu caso usando uma SP para retornar o estoque somente no momento que seria necessário, como que ficaria um caso parecido ao citado acima. Me desculpe mas não estou conseguindo visualizar uma solução.


-----Mensagem original-----
De: lista [mailto:lista-bounces em firebase.com.br] Em nome de Adilson B. Cápua Jr.
Enviada em: sexta-feira, 28 de julho de 2017 01:53
Para: FireBase <lista em firebase.com.br>
Assunto: Re: [firebase-br] Dúvida com controle de estoque

Boa noite, Marcelo!

Então, eu faço algo mais ou menos parecido com o que você citou, tanto para estoque, quanto para qualquer tipo de movimentação que exista um saldo, como o controle de estoque citado por ti e também um caixa, onde temos um valor saldo que é calculado em relação e entradas (créditos) e saídas (débitos).

O que eu utilizo é uma SP que faz todo o serviço, ou seja, passo para ele o ID do produto e ele pega todas as saídas e depois todas as entradas e calcula o saldo. Eu não tenho um campo "SALDO ATUAL" na minha tabela, pois o saldo é calculado no momento que se precisa dele. Dessa forma, evita-se erros de inconsistência com saldos, ou seja, o cálculo do saldo só é feito com o que realmente está efetivado!

Em um passado remoto eu trabalhei dessa forma que você citou. Tinha um campo SALDO e eu ia somando ou subtraindo, de acordo com a operação. Isso ocasiona muitos erros, pois às vezes em uma alteração, o usuário podia ir no registro de saída que tinha 10 por exemplo, alterava para 15. Depois o usuário se arrependia do que fez e cancelava a alteração! Já viu o que poderia acontecer, né? Da forma como eu trabalho isso não existe!

Quanto a questão de performance, pode ficar despreocupado que o Firebird é um banco espetacular em se tratando disso. É um dos únicos bancos relacionais que pode ser instalado em máquinas bem "humildes" mesmo! Eu já tive clientes que usavam como servidor um Celeron com 2 GB de RAM e o sistema funcionava muito bem! Claro que você precisará otimizar bem as suas querys para que o mínimo de dados possíveis seja buscado, mas isso já é uma prática comum até para quem tem um servidor dedicado e potente (um XEON, por exemplo, com 32 GB RAM e SSD 1 TB)! Mesmo com essa configuração aí citada, se você tiver uma query mal-formulada, usando índices complexos e mau-determinados, você vai ter problemas com performance!

O pessoal aqui da lista vai confirmar isso, mas performance tem mais a ver com a forma que você lê e grava no seu banco (seja ele qual for) do que com a máquina em si!

Boa sorte!

_____________________________________
  Adilson Bragança Cápua Jr.
  Linhares - ES                            Brasil

  Mail:* juniorcapua em me.com <juniorcapua em me.com>*
*          juniorcapua em gmail.com <juniorcapua em gmail.com>*
*          juniorcapua em yahoo.com.br <juniorcapua em yahoo.com.br>*
  Messenger:* juniorcapua em live.com <juniorcapua em live.com>*
  Skype:* dellas_capua*
  Blogger: http://dellasnoites.blogspot.com/ _____________________________________
"Save a tree! Send an e-mail!"

Em 27 de julho de 2017 23:58, Marcelo - MK Softwares < marcelo em mksoftwares.com.br> escreveu:

> Boa noite.
>
>
>
> Estou com uma duvida com relação a normalização do banco de dados para 
> com o controle de estoque.
>
> Vou apresentar o meu cenário atual:
>
> - Versão do banco 2.5;
>
> - Possuo muito clientes que possuem computadores com pouco poder de 
> processamento (várias pequenas empresas com apenas um computador);
>
> - O controle de estoque esta sendo realizado mediante atualização do 
> saldo do estoque do produto no campo “EstoqueAtual”, onde quando se 
> ocorre uma entrada ou saída o software de gestão faz a leitura do 
> registro do produto, pega o saldo atual no estoque e faz a atualização 
> do mesmo (entrada ou saída). Após isso é feito um update no registro 
> com o valor do estoque atualizado.
>
>
>
> Baseado nessas informações observei que não é correto (pelo menos 
> creio eu), então estou pensado de criar uma tabela onde possa 
> armazenar as movimentações. Desse modo apenas iria fazer um insert com 
> os valores do produto que se esta movimentando. Onde um campo teria 
> uma flag: D ou C (débito ou credito), e através de uma trigger 
> disparar uma atualização no campo “EstoqueAtual” da tabela de 
> produtos, retornando para a mesma o saldo em estoque do produto.
>
>
>
> Bom até ai esta muito bonito e legal (pelo menos no meu pensamento), 
> mas a dúvida que não quer calar:
>
> - Fazendo desse modo não ficará lento, para computares menos 
> favorecidos de processador, quando o banco de dados estiver enorme, 
> digo vários registros nessa tabela?
>
> - Na minha opinião essa trigger será mais ou menos assim: Executará um 
> SELECT SUM para todas as flags “D” e outro SELECT SUM para todas as 
> flags “C”, para o produto movimentado. De posse dos dois valores, 
> executar um update na tabela de produtos com a diferença dos dois valores.
>
> - Caso este modo esteja errado, qual a sugestão que me aponta para 
> este problema?
>
>
>
> Desde já agradeço a todos.
>
>
>
> ______________________________________________
> FireBase-BR (www.firebase.com.br) - Hospedado em www.locador.com.br 
> Para saber como gerenciar/excluir seu cadastro na lista, use:
> http://www.firebase.com.br/fb/artigo.php?id=1107
> Para consultar mensagens antigas: http://www.firebase.com.br/ 
> pesquisa_lista.html
>
______________________________________________
FireBase-BR (www.firebase.com.br) - Hospedado em www.locador.com.br Para saber como gerenciar/excluir seu cadastro na lista, use: http://www.firebase.com.br/fb/artigo.php?id=1107
Para consultar mensagens antigas: http://www.firebase.com.br/pesquisa_lista.html





Mais detalhes sobre a lista de discussão lista