Interpretação de Queries

Bugs
#1

Pessoal,

Essa versão aparece com um monte de problemas relacionados às queries.

Eu estou encontrando o seguinte problema:

Tenho uma tabela que contém um campo com a seguinte nomenclatura -> clieparam_smtp_[size=12pt]from[/size]. Esse from no final do nome do campo é reconhecido como sendo o FROM da instrução SELECT, exemplo:

SELECT
clieparam_id,
clieparam_smtp_[size=12pt]from[/size]
[size=12pt]FROM[/size]
clieparam
WHERE
clientes_id = {clientes_id}

No momento da geração dos fontes aparece um erro informando que o campo clieparam_smtp_ (sem o from no final). Ou seja, ele não reconhece o campo que contém a terminação [size=12pt]from[/size].

Solução -> tive que renomear todas as aplicações de todos os projetos que continham referência a campos com esse tipo de terminação (from)… como é uma tabela de parâmetros imaginem a quantidade de aplicações que foram corrigidas…

E mais, desde o lançamento da versão BETA reclamei de problemas desta natureza (interpretação da query), alguns foram corrigidos - ainda assim porque fiz um esforço imenso pra entender o que estava ocorrendo, elaborar um vídeo e solicitar correção - outros como este continuam (se não estiver bem entendido faço um vídeo).

Forte Abraço.

#2

Acabei de testar novamente agora na 7.009 que saiu hoje.

E continua o mesmo erro se usar JOIN para unir 2 tabelas e colocar a SQL lá manualmente que tenha as tabelas com nome da tabela.(ponto).campo ele reconhece os campos números como TEXTO.

E eu tenho uma aplicação financeira para começar esta semana que o pessoal só trabalha com valores, resumindo tô PARADO.

Estou usando o MYSQL 5.6

#3

Boa tarde,

Reportei este problema para nossa equipe de bugs.

att,
Bernhard Bernsmann

#4

Jailton,

Aconselho você tirar o nome do schema (aliases) nas queries… os códigos ficam muito grandes desnecessariamente.

Com relação aos JOINs, se essas tabela não forem muito populadas, você poderia substituir por subselects que teria o mesmo efeito sem perda de performance.

Tente aí e post o resultado.

#5

Grato.

E qual construção escolher ?

Acho que já está bem claro que não existem diferenças entre junções via JOINs ou via cláusula WHERE do ponto de vista de desempenho. Se ambas produzem o mesmo resultado, qual seriam as razões para preferir uma construção específica ? Em minha opinião sou completamente a favor do INNER JOIN em relação a junções na cláusula WHERE pelas seguintes razões:

§ Clareza de código: O uso de JOINs não polui o código. As junções na cláusula WHERE confundem, pois, não se sabe apenas com uma olhada o que é filtro e o que é junção. É muito ruim encontrar um instrução SQL com 20 condições variando entre junções e filtros.

§ Possibilidades de otimização: Apenas a junção via JOIN permite que se influencia no algoritmo de junção (Nested Loops, Merge Join ou Hash Join)

§ Evolução: Se o padrão ANSI92 especifica operadores de junção específicos não vejo porque não utilizá-los. Essa definição foi há oito anos atrás. Especificar junções em cláusula WHERE só demonstra uma certa resistência em evoluir e adotar notações mais modernas.

§ Flexibilidade: Suponha que uma junção seja feita via cláusula WHERE e que posteriormente o efeito INNER JOIN tenha de ser substituído por um OUTER JOIN ? Se a junção foi feita via JOIN basta trocar algumas palavras chaves. Se a junção foi feita via cláusula WHERE pode ser bem mais complicado

Acho que estão bastante detalhadas as questões relacionadas a desempenho entre junções no INNER JOIN e na cláusula WHERE. Sei que essa dúvida não morrerá aqui e certamente muitos outros aparecerão com ela. Irei sempre utilizar a comparação do chumbo e do algodão. Afinal qual será mais pesado ? Um quilo de chumbo ou algodão ? Aqueles que acharem que o de chumbo é mais pesado normalmente tendem a achar que o INNER JOIN é mais performático que a cláusula WHERE.

#6

Jailton calma lá!

Meu palpite foi apenas tentar ajudar na solução do seu problema… esperar pela NM pode demandar tempo que eu não sei se você tem… todos por aqui sabemos como essas coisas andam e, como apenas você está tendo este problema, é bem possível que a maioria absoluta não utilize as declarações JOINs (INNER, LEFT ou RGHT) ou já tenham tentado contornar a situação utilizando outros artifícios.

Como você apresentou o erro e já sabe a causa, então apresentei possíveis soluções: uma referente à inclusão do nome do schema nas queries (totalmente desnecessário) e outra utilizando subselects em substituição aos JOINs. Apenas isso.

Não sou especialista em SQL, sou autodidata, apenas submeto uma possível solução a uma carga de dados mais intensa pra testar o resultado e nas instruções JOINs os resultados têm sido melhores que a utilização de subselects.

Forte abraço.

#7

Toinnnn… :stuck_out_tongue: num intendi foi nada… chumbo…ou algodão eis a questão!! Gente vamos nos ater a solução!! Só mais uma coisa… JOIN´s tem sim melhor performance, isso não é questão de achar e sim de testar e testar de novo e ler e discutir sobre essas possibilidades.

#8

Concordo Sr. Jovito,

Falta mais inteligência nos algorítimos que interpretam as Querys na gerador do código.

Caso parecido:
http://www.scriptcase.com.br/forum/index.php/topic,6684.0.html

#9

Carol,

Inicialmente deixe o Sr pra lá… o Haroldo está bem, pede a ele pra mandar notícias.

Esse caso que você mencionou é tipo clássico da intervenção do SC nas queries… isso não deveria estar acontecendo. Antes do lançamento da V7 a NM disponibilizou para alguns usuários uma versão Beta - e eu recebi uma - para testes. Nos primeiros testes a quantidade de problemas foi tão intensa que eu informei pra eles e desisti de usar, estava impraticável. Muita coisa foi resolvida mas alguns casos isolados, com pouco uso, ainda permaneceram e agora nós estamos identificando-os.

Vamos aguardar um posicionamento.