MySql, ajuda com comando SELECT

[alxsts]

Olá!

tenho o campo NUMMOV que eh NUMERICO e AUTOINCREMENT. Cada lançamento tem um NUMMOV diferente.

Isto é exatamente o que precisávamos. Basta adaptar a consulta que postei antes:

SELECT *
  FROM a04mov t1
 WHERE t1.datmov <= 20131231
   AND t1.is_deleted = 'N'
   AND t1.nummov = (SELECT Max(nummov)
                      FROM a04mov
                     WHERE codprd = t1.codprd
                       AND is_deleted = 'N'
                       AND datmov <= 20131231)
ORDER BY t1.codprd

Isto funciona desde que não sejam feitos lançamentos com datas retroativas.

[janio]

Alexandre,

Num deu ainda pra testar sua solução, mas logo logo o farei.

Tbm irei testar uma outra possível solução postada por um colega em outro fórum:

http://forum.imasters.com.br/topic/5261 ... da-tabela/

SELECT t1.mov, t1.produto, t1.saldo. t1.`data`
FROM tabela t1, ( SELECT produto, Max(data) `data` FROM tabela GROUP BY produto
) v WHERE t1.produto = v.produto AND t1.`data` = v.`data`

Primeiro, eu listo todos os registros da tabela `tabela`, ou `t1`(ALIAS), depois eu faço uma subquery com a consulta que você criou, pois nela é retornado o id do produto e a data da última ocorrência, e dentro do WHERE eu relaciono as duas "tabelas", a tabela `t1` e a tabela virtual `v`.

Janio

[alxsts]

Olá!

Ok Janio.

Esta outra solução que você mostra, nada mais é que a primeira que postei.

No teu caso não vai funcionar pois você não tem a informação de data e hora de cada lançamento na tua tabela (tem apenas a data). Assim, o resultado de Max(data) vai retornar a maior data para cada produto mas, como você tem vários registros do mesmo produto na mesma data, é impossível ter certeza de que se está lendo o último lançamento de cada produto na data.

Considere, em seus projetos futuros, analisar a necessidade de se colocar campos datetime ao invés de apenas date.

[janio]

Alexandre,

O seu código funciona, porém tem o detalhe q vc falou: nao pode haver lançamentos com datas retroativas! Mas no caso, eu permito isso no meu sistema.

A solução final q cheguei foi essa:

SELECT t1.nummov, t1.codprd, t1.sldstk, t1.datmov FROM a04mov t1, (SELECT codprd, Max(datmov) as data FROM a04mov WHERE DATE(datmov) < '2013-12-31' GROUP BY codprd) v WHERE t1.codprd = v.codprd AND t1.datmov = v.data order by codprd

Detalhe: o código retorna todos os lançamentos da maior data q seja menor q 31.12.2013. Assim, se o PRODUTO A, por exemplo, tiver 5 lançamentos no dia 30.12.2013, sera retornado todos os 5. Mas posso colocar isso dentro de um Do While e pegar apenas uma dessas datas. Deu pra eu mim virar aqui.

Uma coisa q notei foi q esse negocio de query dentro de query deixa as consultas muuuuuuuuuito mais lentas.

Brigadao Alexandre!

Janio

[alxsts]

Olá!

Mas posso colocar isso dentro de um Do While e pegar apenas uma dessas datas.

Mas como vai identificar o saldo final de cada data?

Uma coisa q notei foi q esse negocio de query dentro de query deixa as consultas muuuuuuuuuito mais lentas.

Depende do teu modelo de dados. Se você tiver nas tuas tabelas os índices apropriados fica "bala".
Além disto, o modo como você está fazendo não é indicado. Colocou um SELECT com GROUP BY para criar uma coluna (coluna V) e depois fazer o JOIN com a outra consulta. Creio que a forma que te passei será mais rápida.

Dica básica para tabelas de bancos de dados relacionais: se a coluna não é a PRIMARY KEY da tabela (sempre tenha uma PK em cada tabela), procure criar índice para todos os campos usados frequentemente na cláusula WHERE dos teus SELECTS.

Crie o índice abaixo na tua tabela e verifique se houve alguma alteração na performance (tempo de resposta) da consulta:

ALTER TABLE `a04mov` ADD INDEX `idx_a04mov_CodPrd_Dat_Mov`(`CodPrD`, `DatMov`);

Minha tabela de testes tem apenas 18 linhas. Tanto a tua query quanto a minha executaram num tempo médio de 15 milissegundos com ou sem o índice (MariaDB). Verifique no teu sistema, onde tem bastante informação nas tabelas, se o tempo de resposta melhora.

[janio]

Alexandre,

Na verdade uso Mediator + Mysql, e resolvi modificar todos os meus relatórios para consultas sql em vez de comandos xbase.

Tem melhorado bastante o desempenho e dxei de lado criação de dbfs e índices temporários. Estou buscando uma futura 'independência' do xbase para comandos totalmente sql. Comecei pelos relatórios...

Bom, como falei, ta muuuuuito lenta essa consulta. Ambas. Impraticável. Estou testando numa base com 40mil lançamentos e o sistema simplesmente trava. Não devolve a consulta de jeito nenhum. Nem usando o heidisql... Da até pra ir dormir! Tenho clientes com mais de 1milhao de lançamentos nessa tabela. Agora imagina ae uma consulta dessa numa base dessa!

Essa tabela já tem os índices:

Nummov tag1
Str(codprd)+str(nummov)+dtos(datmov) tag2
Dtos(datmov) tag3

O índice q vc sugeriu em comandos xbase, seria como mesmo pra eu poder testar aqui a velocidade????

PS: preciso criar o indice com comando xbase pra manter a compatibilidade com Mediator.

[janio]

Pessoal,

Pra fechar este post, informo q nenhuma das duas soluções encontradas funcionaram a contento. Até q funcionaram muito bem numa base de dados bem pequena, mas na minha base de teste com cerca de 300mil registros na tabela, simplesmente a consulta num retorna com os resultados. E olha q tenho clientes com mais de 2milhoes de registros apenas nessa tabela. INVIÁVEL!

Criei com comandos sql mesmo o indice sugerido. Executei a query pelo HeidSql... e nada. Pensando ser um 'problema' no heidi, decidi fazer a consulta diretamente por linha de comando no mysql atraves do prompt. Parece brincandeira, mas o meu computador passou a noite interia executando essa query, mas nada de retorno.

Minha maquina q eh lenta??? talvez, um notebook dell com 8gb de memoria e processador core i5.

DESISTO!

Vou procurar outra solução, talvez copiando toda a tabela para um dbf temporario e daí manipula-lo à vontade.

Obrigado a todos, principalmente ao Alexandre (AlxSts)

Janio