Queria fazer no SQL a mesma função do excel, no caso REMOVER DUPLICADOS, ou seja, como tenho 5 filiais, e itens entram em uma e não na outra, e preciso subir para o site todos os itens disponíveis para venda, mesclando todos os itens disponíveis nas 5 filiais, no DBF basta fazer um seek e localizar, os itens que não constam.
Pela minha logica tentei dessa maneira, mais o processamento vai la em cima e causa erro não retornando nada
SELECT e1.DESCRICAO, e1.ean, e1.codigo,
COALESCE(e2.sku,0) AS EAN_SITE,
COALESCE(e2.NOME,'NAO LOCALIZADO') AS DESCRICAO_SITE,
COALESCE(e2.ean, 'NAO LOCALIZADO') AS SKU_SITE
FROM PORTAIS.xestoque e1
LEFT JOIN AGILLE54_API.tray_produtos e2 ON e2.sku = e1.CODIGO
ORDER BY e1.CODIGO
Ja se eu inverter a ordem faz em: Registros encontrados: 22.618 Avisos: 0 Duração de 1 consulta: 26,453 seg. (+ 0,016 seg. rede)
SELECT e1.NOME, e1.ean, e1.SKU,
COALESCE(e2.CODIGO,0) AS EAN_SITE,
COALESCE(e2.DESCRICAO,'NAO LOCALIZADO') AS DESCRICAO_SITE,
COALESCE(e2.ean, 'NAO LOCALIZADO') AS SKU_SITE
FROM AGILLE54_API.tray_produtos e1
LEFT JOIN PORTAIS.xestoque e2 ON e1.SKU = e2.CODIGO
ORDER BY e1.SKU
Por que a diferença, se mudei somente a ordem?
Com isso, consegui fazer mais ou menos o que preciso, mais se exister maneira mais pratica, gostaria saber...
gilbertosilverio escreveu:Por que a diferença, se mudei somente a ordem?
Isto depende de como foram definidas as tabelas. Se tem primary key, se tem índice. Como não tem WHERE, o otimizador procura o modo mais econômico de fazer.
- Qual gerenciador de BD está usando?
- Qual é a versão do gerenciador?
- Quer apenas pesquisar itens faltantes em duas tabelas E / OU remover duplicados?
- O que quer dizer com "remover duplicados"? Deletar da tabela? Fazer com que não apareçam no resultado da consulta?
- Qual das tabelas pode ter itens faltantes? xestoque ou tray_produtos ?
gilbertosilverio escreveu:Com isso, consegui fazer mais ou menos o que preciso, mais se exister maneira mais pratica, gostaria saber...
Deve existir mas precisamos de mais informações...
Descobri por que um era mais rápido que o outro, devido a indexação do campo. As tabelas do site sao indexadas, indexei o campo da xestoque que criei, a qual nao tinha indexado, e ficou igualmente rápido.
Tenho meus vícios em programação com DBF de 30 anos, e estou começando a aprender como o SQL funciona, e as maravilhas que da pra fazer com ele...
Vou tentar explicar o que queria fazer, já faço com DBF, mais queria ver como fazer com SQL.
Tenho cinco filiais, cada qual com seu estoque. Ocorre que preciso subir pro SITE, todos os itens novos que por ventura são incluídos diariamente.
O pessoal que desenvolveu o site criou as tabelas deles, hoje faço a inclusão por planilha do Excel, ou seja, baixo do site, crio uma planilha dos itens cadastrados lá, filtro em todos os sistemas nossos itens, comparo com a lista do site, removo os itens que já existem e somente incluo os novos.
A rotina que fiz e rápida, mais depende de um operador.
Com a velocidade de pesquisa que já consegui com o SQL, pretendo mesclar todos os estoque e comparar com o que esta no site e subir somente os novos itens.
Estou em testes, não uso ainda o sql em produção, somente estou testando e comparando com o que já tenho, e já consegui fazer rotinas bem mais rápidas.
Estou testando com MARIADB 10.5 na versão 64, e usando ADO baseado nos exemplos do Quintas e do pessoal aqui do fórum, e MARIADB ODBC 32.
Esta rotina que postei, eu filtro em uma matriz os NAO LOCALIZADOS e subo para a base do site, e funcionou perfeitamente, como faço com DBF.
E só mesmo a titulo de aprendizagem, quem sabe daqui uns 30 anos eu esteja craque no SQL kkkkk
gilbertosilverio escreveu:Esta rotina que postei, eu filtro em uma matriz os NAO LOCALIZADOS e subo para a base do site, e funcionou perfeitamente, como faço com DBF.
E só mesmo a titulo de aprendizagem, quem sabe daqui uns 30 anos eu esteja craque no SQL kkkkk
Já criou o que precisava, e procurou descobrir sobre deixar mais rápido.
E sempre vão inventar novidades no SQL pra fazer as coisas de forma mais rápida.
A partir do momento que começa a usar, vai descobrindo como é rápido e prático, e vai indo mais fundo.
É exatamente assim que funciona, nem precisou dos 30 anos.
Na prática já começou a ficar craque e nem percebeu kkkk
José M. C. Quintas
Harbour 3.2, mingw, gtwvg mt, fivewin 25.04, multithread, dbfcdx, MySQL, ADOClass, PDFClass, SefazClass, (hwgui mt), (hmg3), (hmg extended), (oohg), PNotepad, ASP, stored procedure, stored function, Linux (Flagship/harbour 3.2) "The world is full of kings and queens, who blind our eyes and steal our dreams Its Heaven and Hell" https://github.com/JoseQuintas/
Só para ficar registrado, consegui fazer o que precisava direto no SQL, baseado em um link do Alexandre, sobre a Teoria dos conjuntos, coisa que aprendi na 5 serie, e olha que faz tempo, e so agora vi pra que server... kkkkkkkkkk
Com descrevi, tenho duas filias e preciso filtrar somente os itens não relacionados entres elas, ou seja
SELECT e1.DESCRICAO, e1.ean, e1.codigo,
COALESCE(e2.codigo,0) AS CODIGO_NOVO,
COALESCE(e2.DESCRICAO,'NAO LOCALIZADO') AS DESCRICAO_NOVO,
COALESCE(e2.ean, 'NAO LOCALIZADO') AS EAN_NOVO
FROM PORTAIS.xestoes e1
RIGHT JOIN xestodies e2 ON e2.codigo = E1.CODIGO
WHERE E1.CODIGO IS NULL
UNION
SELECT e1.DESCRICAO, e1.ean, e1.codigo,
COALESCE(e2.codigo,0) AS CODIGO_NOVO,
COALESCE(e2.DESCRICAO,'NAO LOCALIZADO') AS DESCRICAO_NOVO,
COALESCE(e2.ean, 'NAO LOCALIZADO') AS EAN_NOVO
FROM PORTAIS.xestodies e1
RIGHT JOIN xestoes e2 ON e2.codigo = E1.CODIGO
WHERE E1.CODIGO IS NULL
