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

Adilson B. Cápua Jr. juniorcapua em gmail.com
Sex Jul 28 10:14:32 -03 2017 

Eu, no meu caso, usava/uso uma query para montar uma tabela temporária em
memória para preparar o relatório. Tenho um cliente com um cadastro de
aproximadamente 80 mil produtos e um relatório de saldo de estoque leva em
torno de 10 segundos do momento em que o usuário clica no botão "GERAR
RELATÓRIO" até o mesmo ser exibido! Com a query em memória, depois posso
fazer um simples select (inclusive com filtros) e tudo flui tranquilamente!

Qualquer coisa, estamos aí pra ajudar!

Um abraço!

_____________________________________
  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 28 de julho de 2017 09:44, Marcelo - MK Softwares <
marcelo em mksoftwares.com.br> escreveu:

> 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
>
>
> ______________________________________________
> 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