CONTROLAR ESTOQUE
Bom dia pessoal,
Li esse tópico ao poucos dias
http://vbmania.com.br/index.php?modulo=forum&metodo=abrir&id=467035&pagina=1
Eu já faço assim ( Entradas - Saidas ), porém fico na cruel dúvida,
Eu gravo a Saida como -X (negativo) e entrada positivo.
Pois a cada item eu consulto o estoque para saber a disponibilidade.
Fico me perguntando se com o passar do tempo, e milhares e milhares de registros não causará lentidão usando o SUM(Qtd) ?
Será que pela questão de performance não seria ideal ter um campo para guardar/apontar a quantidade,
Eu conversei com um colega, ele me disse que usa um campo para apontar a referência de quantidade.
Alguém aqui tem problema com performance usando o SUM ?
Li esse tópico ao poucos dias
http://vbmania.com.br/index.php?modulo=forum&metodo=abrir&id=467035&pagina=1
Eu já faço assim ( Entradas - Saidas ), porém fico na cruel dúvida,
Eu gravo a Saida como -X (negativo) e entrada positivo.
Pois a cada item eu consulto o estoque para saber a disponibilidade.
Fico me perguntando se com o passar do tempo, e milhares e milhares de registros não causará lentidão usando o SUM(Qtd) ?
Será que pela questão de performance não seria ideal ter um campo para guardar/apontar a quantidade,
Eu conversei com um colega, ele me disse que usa um campo para apontar a referência de quantidade.
Alguém aqui tem problema com performance usando o SUM ?
Assim, são casos e casos. Quando você tem um só estoque, pequeno com poucas mercadorias, geralmente controlado por uma pessoa e não vai nunca expandir, então essa maneira pode funcionar, veja bem: PODE.
O caso é que na grande maioria dos casos, só a quantidade de um produto é informação quase inútil. Temos:
- Métodos de gestão de estoque: FIFO(PEPS), FILO(UEFS). São modelos que necessitam um controle rigoroso de entrada e saÃda de cada lote de produto, muito usado em casos de estoque com produtos perecÃveis.
- Múltiplos pontos de saÃda de estoque: Esse é o caso que já mata o [Ô]campo para quantidade[Ô]. Imagine uma loja em que existem 10 vendedores e todos eles podem dar baixa de produtos no estoque(vender), quando o vendedor A está concretizando a venda do produto X, o vendedor B já deu baixa no último produto. Isso em uma situação de estoque único, imagine quando temos vários depósitos, e vários sub-depósitos, onde vários vendedores de várias lojas todos consultam e vendem. A coisa complica bastante.
Então você pode dizer: Mas meu sistema é pequeno e meu cliente não pensa em aumentar. Cá entre nós, nós sabemos bem como funciona a mente do usuário. Ele geralmente não sabe o que quer, é sempre [Ô]um sisteminha[Ô], [Ô]uma telinha[Ô], [Ô]uma coisinha de nada[Ô]. Se você for na dele, vai acabar tendo que ficar vários fins de semana à fio construindo um sistema de estoque bem mais complexo que o inicialmente combinado e o pior, adequando dados o que pode ser um [Ô]Deus nos acuda[Ô]. Então, a melhor alternativa é fazer o caminho mais longo, onde mesmo para um pequena aplicação(pequeno cliente), você oferece um sistema parrudo que vai suportar qualquer coisa que ele queira expandir no futuro. é aquela coisa, é melhor ter uma arma e nunca usar, do que não ter e precisar.
O caso é que na grande maioria dos casos, só a quantidade de um produto é informação quase inútil. Temos:
- Métodos de gestão de estoque: FIFO(PEPS), FILO(UEFS). São modelos que necessitam um controle rigoroso de entrada e saÃda de cada lote de produto, muito usado em casos de estoque com produtos perecÃveis.
- Múltiplos pontos de saÃda de estoque: Esse é o caso que já mata o [Ô]campo para quantidade[Ô]. Imagine uma loja em que existem 10 vendedores e todos eles podem dar baixa de produtos no estoque(vender), quando o vendedor A está concretizando a venda do produto X, o vendedor B já deu baixa no último produto. Isso em uma situação de estoque único, imagine quando temos vários depósitos, e vários sub-depósitos, onde vários vendedores de várias lojas todos consultam e vendem. A coisa complica bastante.
Então você pode dizer: Mas meu sistema é pequeno e meu cliente não pensa em aumentar. Cá entre nós, nós sabemos bem como funciona a mente do usuário. Ele geralmente não sabe o que quer, é sempre [Ô]um sisteminha[Ô], [Ô]uma telinha[Ô], [Ô]uma coisinha de nada[Ô]. Se você for na dele, vai acabar tendo que ficar vários fins de semana à fio construindo um sistema de estoque bem mais complexo que o inicialmente combinado e o pior, adequando dados o que pode ser um [Ô]Deus nos acuda[Ô]. Então, a melhor alternativa é fazer o caminho mais longo, onde mesmo para um pequena aplicação(pequeno cliente), você oferece um sistema parrudo que vai suportar qualquer coisa que ele queira expandir no futuro. é aquela coisa, é melhor ter uma arma e nunca usar, do que não ter e precisar.
E olha que nem mencionei casos em que existe projeção de compra e análise de custo de compras. Imagine que no seu estoque, você compra, sei lá, meias. Um mês o comprador fez uma compra de 1000 pares à R$ 1,00 cada. No mês seguinte, novamente uma compra de 1000 pares, mas dessa vez à R$ 1,20. O caso é que as que foram compradas por R$ 1,00 ainda não saÃram todas e agora você tem digamos 200 pares que foram compradas à 1 real e mais 1000 que foram compradas à 1,20. Nesse caso toma-se decisão administrativa, ou aumenta o preço de venda de todas as meias ou de nenhuma. Mas se o controle de estoque estiver com controle de lotes correto, é possÃvel saber quando o lote das meias de 1 real acaba para só então fazer o ajuste do preço de forma automática, sem precisar decisão administrativa. Isso é um caso, use a imaginação: Compra de um fornecedor em uma semana à 1 real, na semana seguinte à 1,20, na seguinte muda o fornecedor e compra à 0,85, na seguinte a 0,80. Então você descobre que as tais meias mais baratas eram falsificadas e pelo contrato de venda você pode devolver, daà sai a cata de quais são as falsificadas... enfim, use a imaginação para todos os cenários possÃveis. Como vai adequar isso tudo com um único campo com um valor?
eu não gerencio ainda a questão do FIFO e FILO. ( por enquanto )
mas veja, a situação em questão no momento é a performance.
Olha o que um colega acabou de me dizer:
Será que se fizer um gerenciamento do campo Quantidade usando gatilhos não daria certo ?
Pois no meu ver, independente de concorrência, o gatilho se bem feito, só iria executar 1 por vez.
mas veja, a situação em questão no momento é a performance.
Olha o que um colega acabou de me dizer:
Citação:só a de Venda Itens Pdv fora a de NFe tem 11.856.523 fiz um SUM simples com um GROUP BY e demorou 28 segundos. Se contar que não fiz join com a de cadastro de produtos, se tivesse feito ai o tempo dobraria.
Será que se fizer um gerenciamento do campo Quantidade usando gatilhos não daria certo ?
Pois no meu ver, independente de concorrência, o gatilho se bem feito, só iria executar 1 por vez.
Como mencionei no outro tópico. Views Indexadas
Citação::
Como mencionei no outro tópico. Views Indexadas
Eu já uso uma view para listar o estoque, Porém não indexada, irei dar uma olhada no artigo que vc deixou no link.
.
Colegas,
Bem, cada caso é um caso. Eu, particularmente, tenho uma tabela para cabeçalho de documentos e outra para itens. O estoque de entrada (o que soma nas quantidades) é soma dos itens de cada documento de entrada e o estoque de saÃda (o que diminui as quantidades) é a soma dos itens dos documentos de saÃda.
Isto me permite, inclusive, saber a posição de estoque em determinado perÃodo (quanto se tinha entre determinado perÃodo ou até data especÃfica, bastando considerar também a data de emissão da tabela de cabeçalho).
é tudo muito rápido. Tenho views para estas questões. Exemplo: um cliente (mercado) tem 7 PDVs, em média são feitas 130 NFCe por dia, cada NFCe com média de 40 itens, isto dá um total médio de 144.000 registros mensais a mais na tabela de itens. Quando consulto o estoque, a exibição é praticamente instantânea (clicou, exibiu).
Tudo de bom.
Bem, cada caso é um caso. Eu, particularmente, tenho uma tabela para cabeçalho de documentos e outra para itens. O estoque de entrada (o que soma nas quantidades) é soma dos itens de cada documento de entrada e o estoque de saÃda (o que diminui as quantidades) é a soma dos itens dos documentos de saÃda.
Isto me permite, inclusive, saber a posição de estoque em determinado perÃodo (quanto se tinha entre determinado perÃodo ou até data especÃfica, bastando considerar também a data de emissão da tabela de cabeçalho).
é tudo muito rápido. Tenho views para estas questões. Exemplo: um cliente (mercado) tem 7 PDVs, em média são feitas 130 NFCe por dia, cada NFCe com média de 40 itens, isto dá um total médio de 144.000 registros mensais a mais na tabela de itens. Quando consulto o estoque, a exibição é praticamente instantânea (clicou, exibiu).
Tudo de bom.
SINCLAIR,
Você exibi via select Sum,ou sua lista já traz o estoque na ultima linha ?
Você exibi via select Sum,ou sua lista já traz o estoque na ultima linha ?
NILSONTRES
Eu até o momento faço o SUM(Qtd) dentro de uma view.
SINCLAIR
No meu banco é bem parecido com o seu
Tenho as tabelas de cabeçalho, itens, duplicadas e várias outras.
na tabela Cabecalho indico se a operação é de entrada, saÃda ou outras
na tabela itens no campo quantidade eu simplesmente informo um valor positivo para entrada e negativo para saida.
Até o momento não tive problemas, mas postei aqui no intuito de saber como os colegas trabalham com maior volume de dados, pois estou tentando entrar no nicho de indústria e notei que mesmo pequenas industrias o volume de informação é pesado, e como vou trabalhar com muita concorrência ao estoque, penso que vai exigir muito processamento numa maquina que não é a mais aconselhada para ser servidor.
E nem posso falar em fazer upgrade, pq os engenheiros de produção já vem com a questão de viabilidade de custos e bla bla bla.
Dai fico analisando o que vale mais a pena a se fazer.
Eu até o momento faço o SUM(Qtd) dentro de uma view.
SINCLAIR
No meu banco é bem parecido com o seu
Tenho as tabelas de cabeçalho, itens, duplicadas e várias outras.
na tabela Cabecalho indico se a operação é de entrada, saÃda ou outras
na tabela itens no campo quantidade eu simplesmente informo um valor positivo para entrada e negativo para saida.
Até o momento não tive problemas, mas postei aqui no intuito de saber como os colegas trabalham com maior volume de dados, pois estou tentando entrar no nicho de indústria e notei que mesmo pequenas industrias o volume de informação é pesado, e como vou trabalhar com muita concorrência ao estoque, penso que vai exigir muito processamento numa maquina que não é a mais aconselhada para ser servidor.
E nem posso falar em fazer upgrade, pq os engenheiros de produção já vem com a questão de viabilidade de custos e bla bla bla.
Dai fico analisando o que vale mais a pena a se fazer.
As vezes nos importamos tanto com a teoria do tempo de processamento ( que é o certo a se fazer ) que acabamos nos esquecendo de fazer testes, o colega SINCLAIR deu um exemplo disso, o processamento é muito rapido levando em consideração a quantidade de registros, colocar um campo total não é uma solução para seu caso, pois as consultas poderiam ser dinâmicas, como também já dito tipo pesquisar um total por periodo, ou um total por produtos mais vendidos, etc, o que pode ajudar a melhorar um pouco o desempenho é a criação de procedures, etc, isso deixaria a cargo do banco fazer o processamento de algumas consultas.
ps: uma rede mal projetada também pode influenciar no desempenho do programa, e muito.
ps: uma rede mal projetada também pode influenciar no desempenho do programa, e muito.
Colega CLEVERTON,
é isto ai. O caminho é bem este mesmo.
Colega NILSONTRES,
é uma mistura de ambos, pois um dos campos da view já traz a soma.
Exemplo para a view (fazendo aqui [Ô]de cabeça[Ô], não é a mesma estrutura que tenho no banco, óbvio):
Tabela de Produtos: tb_Produtos
Tabela de Cabeçalho: tb_Documentos
Tabela de Itens: tb_Itens
A View seria algo mais ou menos assim:
O select é normal, algo como select * from vw_Produtos where id_do_produto = 123
Usei Coalesce na soma porque se não existirem saÃdas ou entradas para o produto, o campo calculado quantidade virá com 0 (zero) ao invés de null.
Usei left join porque pode existir um produto sem que exista venda para ele, se fosse diferente ao dar select na view para o produto 123 e não existisse movimentação para ele, a view retornaria sem registros, visto que precisaria existir tanto o produto (que existe) quanto movimentação (que não existiria no exemplo acima).
Na view do exemplo pode-se modificar o campo quantidade para ser a soma das saÃdas e criar outro campos chamado por exemplo quantidade_entrada para ser a soma das entradas ou até usar Union entre dois selects (um para as entradas e outro para as saÃdas)
Poderia ainda fazer join com a tabela de cabeçalho para capturar, também, a data de emissão e numero do documento na mesma view que informa as quantidades, assim, em um select na view se saberia qual movimentação de entrada e/ou de saÃda para cada produto houve em cada documento (eu faço isto para criar o XML das NFe, NFCe e também do SPED). Como teria a data de emissão na view, bastaria colocar no where para que se buscasse as saÃdas e entradas em determinado perÃodo.
Lembrando sempre que é importantÃssimo ter as tabelas tabelas bem indexadas. Fica um raio de tão rápido.
Claro que não é o seu caso, porque é bastante experiente, mas conheci um projetista iniciante que criou Ãndices para todos os campos da tabela, imaginando que ficaria cada vez mais rápido. Ficou cada vez mais lento, porque cada inserção, deleção ou alteração na tabela tinha que alterar uma infinidade de Ãndices. E o rapaz me procurou dizendo que o PostGreSQL era lento demais. Argumentei que qualquer SGBD ficaria lento com a estrutura que ele projetou. Dei um livro em PDF sobre normalização e projeto de dados para ele. Aprendeu rápido. Hoje tem a estrutura do banco na empresa que ele trabalha bem afinada, super rápido com relatórios em Crystal Reports (que eu gosto muito, mas ainda prefiro criar [Ô]na unha[Ô]).
Mas eu mesmo já deixei dúvida simples sobre SQL aqui no VBMANIA, com duas noites sem dormir pedi ajuda para os colegas que prontamente me atenderam, o DS2T, por exemplo. Depois fui me convencer que eu precisava, também, da ajuda do sono.
Tudo de bom a todos.
Citação:No meu banco é bem parecido com o seu
Tenho as tabelas de cabeçalho, itens, duplicadas e várias outras.
é isto ai. O caminho é bem este mesmo.
Colega NILSONTRES,
Citação:Você exibi via select Sum,ou sua lista já traz o estoque na ultima linha ?
é uma mistura de ambos, pois um dos campos da view já traz a soma.
Exemplo para a view (fazendo aqui [Ô]de cabeça[Ô], não é a mesma estrutura que tenho no banco, óbvio):
Tabela de Produtos: tb_Produtos
id_produto
descricao_produto
unidade_produtoTabela de Cabeçalho: tb_Documentos
id_cliente
numero_doc
dt_emissao
fl_entrada_ou_saidaTabela de Itens: tb_Itens
id_do_item
id_do_produto
numero_doc
qtdA View seria algo mais ou menos assim:
Create or Replace View vw_Produtos AS
select Produtos.*, coalesce(sum(Itens.qtd),0) as quantidade
from tb_Produtos
left join tb_Itens as Itens on (Itens.id_do_produto = Produtos.id_produto
O select é normal, algo como select * from vw_Produtos where id_do_produto = 123
Usei Coalesce na soma porque se não existirem saÃdas ou entradas para o produto, o campo calculado quantidade virá com 0 (zero) ao invés de null.
Usei left join porque pode existir um produto sem que exista venda para ele, se fosse diferente ao dar select na view para o produto 123 e não existisse movimentação para ele, a view retornaria sem registros, visto que precisaria existir tanto o produto (que existe) quanto movimentação (que não existiria no exemplo acima).
Na view do exemplo pode-se modificar o campo quantidade para ser a soma das saÃdas e criar outro campos chamado por exemplo quantidade_entrada para ser a soma das entradas ou até usar Union entre dois selects (um para as entradas e outro para as saÃdas)
Poderia ainda fazer join com a tabela de cabeçalho para capturar, também, a data de emissão e numero do documento na mesma view que informa as quantidades, assim, em um select na view se saberia qual movimentação de entrada e/ou de saÃda para cada produto houve em cada documento (eu faço isto para criar o XML das NFe, NFCe e também do SPED). Como teria a data de emissão na view, bastaria colocar no where para que se buscasse as saÃdas e entradas em determinado perÃodo.
Lembrando sempre que é importantÃssimo ter as tabelas tabelas bem indexadas. Fica um raio de tão rápido.
Claro que não é o seu caso, porque é bastante experiente, mas conheci um projetista iniciante que criou Ãndices para todos os campos da tabela, imaginando que ficaria cada vez mais rápido. Ficou cada vez mais lento, porque cada inserção, deleção ou alteração na tabela tinha que alterar uma infinidade de Ãndices. E o rapaz me procurou dizendo que o PostGreSQL era lento demais. Argumentei que qualquer SGBD ficaria lento com a estrutura que ele projetou. Dei um livro em PDF sobre normalização e projeto de dados para ele. Aprendeu rápido. Hoje tem a estrutura do banco na empresa que ele trabalha bem afinada, super rápido com relatórios em Crystal Reports (que eu gosto muito, mas ainda prefiro criar [Ô]na unha[Ô]).
Mas eu mesmo já deixei dúvida simples sobre SQL aqui no VBMANIA, com duas noites sem dormir pedi ajuda para os colegas que prontamente me atenderam, o DS2T, por exemplo. Depois fui me convencer que eu precisava, também, da ajuda do sono.
Tudo de bom a todos.
Tópico encerrado , respostas não são mais permitidas