Se não me falha a memória, existem triggers (gatilhos) que você pode colocar nas operações de UPDATE e DELETE do banco para que ele salve esse registro em uma tabela temporária. Aí no caso você iria apenas consultar essa tabela ao invés de fazer um Job comparar os dados de ontem com os de hoje. Dessa forma você vai evitar fazer múltiplas consultas para comparar cada registro fazendo apenas uma que já irá te mostrar o delta de alterações no banco
Só ver se na tabela de produtos tem um campo de update_at que grava a última atualização do produto, se tiver é só buscar com o where com a data superior a último chamada feita
Depende, se essa coluna estiver indexada pra melhorar a performance da busca, beleza. Agora se não, ele vai ter que percorrer todos os registros da tabela da mesma forma. O melhor seria criar um TRIGGER que salva numa tabela temporária, ao salvar ou atualizar, como um amigo falou alguns cometários acima
Conheci um sistema em que a rotina era assim mesmo. Tinha um agendamento para essa rotina que manda uma lista do produtos para o ponto de vendas. Essa lista era comparada com a Base e e retornava a identificação do produtos que sofreram alterações dai ele rodava uma atualização das tabelas somente destes produtos. Trafego baixíssimo de dados usando arquivos em txt e dat. Básico e super eficiente para grandes grades de produtos
Normalmente os ERPs não chamam callbacks externas para não comprometer o sistema!
Se não me falha a memória, existem triggers (gatilhos) que você pode colocar nas operações de UPDATE e DELETE do banco para que ele salve esse registro em uma tabela temporária. Aí no caso você iria apenas consultar essa tabela ao invés de fazer um Job comparar os dados de ontem com os de hoje. Dessa forma você vai evitar fazer múltiplas consultas para comparar cada registro fazendo apenas uma que já irá te mostrar o delta de alterações no banco
Tive um problema parecido há muitos anos e a solução que usei foi exatamente essa. Está lá funcionando até hoje... (+10 anos)
Só ver se na tabela de produtos tem um campo de update_at que grava a última atualização do produto, se tiver é só buscar com o where com a data superior a último chamada feita
Poise… muito provavelmente o campo data ultima atualização já existe… Se não existir é só criar esse campo e atualizar com uma trigger…
Depende, se essa coluna estiver indexada pra melhorar a performance da busca, beleza. Agora se não, ele vai ter que percorrer todos os registros da tabela da mesma forma. O melhor seria criar um TRIGGER que salva numa tabela temporária, ao salvar ou atualizar, como um amigo falou alguns cometários acima
@@jeffersoncarvalho2566 o trigger daria certo sem sombras de dúvida, mas 5000 produtos em banco de dados local é de boa tbm
Obrigado por postar o problema inteiro, kkkk já estavam me chamando de júnior na parte 01 kkk (nada contra)
Conheci um sistema em que a rotina era assim mesmo. Tinha um agendamento para essa rotina que manda uma lista do produtos para o ponto de vendas. Essa lista era comparada com a Base e e retornava a identificação do produtos que sofreram alterações dai ele rodava uma atualização das tabelas somente destes produtos. Trafego baixíssimo de dados usando arquivos em txt e dat. Básico e super eficiente para grandes grades de produtos
Fiz algo parecido integrando um erp de uma imobiliária ao site
O que é RP? 😅
Inteligente
Usa mensageira cara, a cada alteração vc publica uma msg num Kafka por exemplo.
A onde rola essas lives?
Twitch