none
Melhor estratégia para totalizar valores em tabela com grande volume de registros RRS feed

  • Discussão Geral

  • Olá!

    Projetando um banco de dados SQL Server Express 2017, em um cenário com 3 Tabelas: Produto, LocalEstoque, MovimentoEstoque. A tabela de Produto contém milhares de registro, e a de movimento de estoque milhões de registros. A maioria do trabalho será para leitura, onde é preciso com frequência fornecer por Produto e por produto/Local o saldo de estoque bem como a média ponderada do valor dos produtos, de forma geral qual a melhor estratégia para efeito de desempenho?

    1. Criar uma view, que faz o agrupamento dos dados
    2. Criar uma tabela e redundar a totalização dos valores já agrupadas, atualizando a cada novo movimento
    3. Criar uma tabela de fechamento de período, de forma que nessa tabela constem os totais até determinada data, então para fornecer os totais/saldo utiliza-se o total do período já fechado, acrescido do agrupamento das movimentações a partir da data final do fechamento. Atualizando a cada comando de dechamento de período

    Ou alguma outra abordagem?


    Obrigado,



    terça-feira, 23 de julho de 2019 11:44

Todas as Respostas

  • Matheus,

    Este é um tipo de situação bastante comum de se deparar e sua implementação vai depender justamente das necessidades de regras de negócio.

    Respondendo as suas perguntas:

    1 - Criar uma view, que faz o agrupamento dos dados: Sim este pode ser um cenário, específico para se aplicar quando você deseja justamente gerar relatórios com dados sumarizados e apresentar estes resultados para uma análise. O uso da View traz inumeros ganhos quando nos se referimos a manter a integridade, confiabilidade e até mesmo segurança dos dados, sem deixar de destacar questões relacionadas a performance e manutenção. 

    Eu faria uso da view para as suas necessidades de consulta de dados em tela e principalmente para gerar relatórios específicos com estrutura fixas.


    2 - Criar uma tabela e redundar a totalização dos valores já agrupadas, atualizando a cada novo movimento: Eu gosto muito desta abordagem, inclusive é a que ultimamente tenho me deparado mais nas consultorias que venho fazendo em seguimentos específicos: Supermercados, Lojas de Calçados e Roupas, e principalmente empresa de manufatura.

    A utilização desta tabela tabela que permite armazenar e ir sendo atualizada a cada movimentação o saldo em estoque é interessante quando você aplica em conjunto uma outra tabela que vai gerando todo histórico de movimentação, contendo as entradas, saídas e datas de movimentação, a cada ação o saldo vai sendo atualizado.


    3 - Criar uma tabela de fechamento de período, de forma que nessa tabela constem os totais até determinada data, então para fornecer os totais/saldo utiliza-se o total do período já fechado, acrescido do agrupamento das movimentações a partir da data final do fechamento. Atualizando a cada comando de dechamento de período: Outra ótima opção de ser aplicada quando temos a necessidade de realizar estes fechamentos mensais, armazenar os respectivos totais e até mesmo fazer uso destes totais em movimentações futuras, ao similar a um livro caixa. Já implementei este tipo de cenário em um projeto que trabalhava com movimentações de produtos manufaturados e beneficiados em uma determinada empresa que tinha a necessidade de atender uma lei do governo federal chamada de FICHA Modelo 3.

    Ao longo do período de movimentação do produto dentro da empresa, desde sua entrada no almoxarifado, movimentações internas, até se tornar um outro produto ou produto acabado era registrada em fichas específicas contendo a movimentação diária e ao final do mês era gerado o fechamento mensal e seu saldo transportado para o próximo mês, quando esta ficha atingia a marca de 100 linhas de movimentação, todo saldo era finalizado, fechado e transportado para outra ficha.

    Pois bem, pensando sem conhecer seu ambiente, suas necessidades de regras de negócios, acredito que poderiamos aplicar os três cenários para cada necessidades, mas pensando de forma única e específica em um controle de estoque, eu trabalharia com a segunda opção.

    Inclusive quero compartilhar com você um cenário que sempre utilizo como exercício de prática e fixação para meus alunos de graduação e pós-graduação que se aproxima bastante da segunda opção:

    https://1drv.ms/u/s!AjrQ6-4-Es6Jujl9x3JwVVVKFn_P?e=qgzwXw

    Ressalto que este material é utilizando em um ambiente de estudos, existem ajustes e melhorias a serem feitas, mas acredito que de alguma forma poderá lhe ajudar.

    Em relação ao uso do fechamento e controle de movimentação de saldos como eu destaquei anteriormente, caso tenha interesse entre em contato que eu lhe forneço o backup deste ambiente.


    Pedro Antonio Galvão Junior [MVP | MCC | MSTC | MIE | Microsoft Evangelist | Microsoft Partner | Engenheiro de Softwares | Especialista em Banco de Dados Relacional e Data Warehouse | Professor Universitário | @JuniorGalvaoMVP | http://pedrogalvaojunior.wordpress.com]

    terça-feira, 23 de julho de 2019 14:26
  • Deleted
    terça-feira, 23 de julho de 2019 16:16
  • Deleted
    terça-feira, 23 de julho de 2019 19:34
  • Deleted
    quarta-feira, 24 de julho de 2019 00:03
  • Olá Obrigado pelos, retornos!

    Realmente eu não conhecia essa opção de criar o indice para View, parece ser a solução ideal. Iniciei os testes, e o primeiro passo foi acessar esse conteúdo:

    https://docs.microsoft.com/pt-br/sql/relational-databases/views/create-indexed-views?view=sql-server-2017

    Agora seguirei com as validações, obrigado pela ajuda!


    quarta-feira, 24 de julho de 2019 17:45
  • Matheus,

    Sim, esta é uma possibilidade adicionada inicialmene pela Microsoft a partir da versão 2005 do SQL Server, posteriormente a Oracle e outros fornecedores de soluções de SGBDs começaram a analisar.

    Como já destacamos neste e em outros posts, o uso de View Materializada poderá lhe ajudar ainda mais no que se refere a performance e pesquisa de dados, mas como também, já abordamos, e vale ressaltar sempre que criamos um índice a uma View o mesmo fica lógicamente relacionado as tabelas e colunas a qual a view faz referência e sendo assim, quando uma tabela utilizada na View sofrer manipulações: Insert, Update e Delete, seus respectivos índices também serão impactados o que poderá refletir na View.

    Neste caso, tenha em mente que uma View Materializada será mais ágil na pesquisa de dados sempre que seus referidos índices estiverem atualizados, ou seja, ganhamos no Select, mas poderemos nos processos de Insert, Update e Delete, tanto na View como também nas próprias tabelas envolvidas nela.

    Aproveitando uma de suas perguntas no post inicial desta dúvida: Ou alguma outra abordagem?

    Gostaria de destacar a possibilidade de utilizar uma Stored Procedure, ou diversas Stored Procedures para cada uma dos seus processos ou necessidades, recurso poderá lhe ajudar ainda mais na automatização de tarefas, processamentos, manipulação de dados, cálculos, enfim em tudo o que for possível desenvolver dentro do SQL Server.

    No link que eu compartilhei anteriormente para você, caso ainda não tenha acessado, vai poder encontrar implementações e exemplos de Stored Procedure, Trigger e Functions.

    Como foi demonstrado anteriormente em outras posts dentro deste, o uso de Trigger poderá facilitar ainda mais os processos de atualização de dados, eu mesmo, em diversos cenários, gosto de utilizar dentro do Trigger a chamada para o processamento de Stored Procedures, analise também esta possibilidade dentro das suas necessidades.

    Enfim, estamos aqui para ajudar, aprender e transmitir conhecimento, no que for possível conte comigo.


    Pedro Antonio Galvão Junior [MVP | MCC | MSTC | MIE | Microsoft Evangelist | Microsoft Partner | Engenheiro de Softwares | Especialista em Banco de Dados Relacional e Data Warehouse | Professor Universitário | @JuniorGalvaoMVP | http://pedrogalvaojunior.wordpress.com]


    quarta-feira, 24 de julho de 2019 17:54
  • Deleted
    quarta-feira, 24 de julho de 2019 18:10