Trazendo string parcial

por **JoséQuintas** » 20 Nov 2019 09:43

Tem uma coisa que eu não tinha pensado antes:

Tenho lá no browse

SELECT CDNOME, CDENDERECO FROM CLIENTES...

Mas na hora de mostrar, mostro Left( nome, 25 ) e Left( endereco, 25 )

Imagino que ficaria melhor/mais rápido assim:

SELECT LEFT( CDNOME, 25 ) AS NOME, LEFT( CDENDERECO, 25 ) AS ENDERECO FROM CLIENTES...

Imagino que, apesar de ter "cálculo", vai ser menos informação trafegando.
Estou certo?

por **sygecom** » 20 Nov 2019 13:14

Sim,para mim faz todo sentido, tenho alterado aos poucos algumas sintaxe xbase para uso SQL direto e tenho feito isso também.
Se já pode trazer tudo pronto e ordenado, melhor do que ficar consertando no xbase.

por **tonicm** » 20 Nov 2019 19:32

Sim, também uso assim.

Inclusive quando são dados de diversos campos, uso:
SELECT CONCAT(NUMERO, ' - ', REFERENCIA) AS Nome_Artigo

por **JoséQuintas** » 20 Nov 2019 20:39

O detalhe especial que mencionei é sobre cortar string.

SELECT NOME FROM CLIENTES

Mas vou usar num tbrowse, somente 25 caracteres

SELECT LEFT( NOME, 25 ) FROM CLIENTES

No TBrowse, de qualquer jeito vou usar Pad( nome, 25 ), porque pode vir menor que isso.

Não se trata de trazer pronto do MySQL, mas de economizar rede/internet pra transferir informação.
o Texto NÃO vai vir exatamente do tamanho que vou usar, mas não vou desperdiçar velocidade de transferência com excesso de informação inútil.

A dúvida é:
Estou reduzindo tempo e tamanho de comunicação...
Mas como saber quando isso é ruim para o servidor? (tempo do servidor).

por **alaminojunior** » 10 Dez 2019 20:48

Acredito que só num banco com uma massa muito grande de dados possa fazer essa aferição e chegar num veredicto.
Como serão menos bytes para transferir via rede,com certeza haverá economia de tempo, então essa questão está quitada.
Com relação ao "esforço" do servidor, eu costumo testar
(no heidisql) as sentenças antes de embutir no prg, sempre procurando trazer os dados no menor tempo possível. Às vezes um detalhezinho faz enorme diferença.

Não sei como o motor do banco trabalha, se ele pega cada campo e depois tira o pedaço (o que a princípio demanda mais esforço) ou só pega o pedaço requisitado ...
Boa pergunta !

por **tonicm** » 11 Dez 2019 08:06

Fiz um teste com uma bd com mais de 1 milhão de registos.
Ficou mais rápido com o left.

Retornar apenas os 3 primeiros carateres:

/* Affected rows: 0  Found rows: 1.661.102  Warnings: 0  Duration for 1 query: 0,000 sec. (+ 1,593 sec. network) */
SELECT LEFT(m.N_SERIE,3)
FROM movimentos m
INNER JOIN movimentos_tipos t ON t.NUMERO=m.TIPO
;
/* Affected rows: 0  Found rows: 1.661.102  Warnings: 0  Duration for 1 query: 0,015 sec. (+ 1,578 sec. network) */
SELECT LEFT(m.N_SERIE,3)
FROM movimentos m
INNER JOIN movimentos_tipos t ON t.NUMERO=m.TIPO
;
/* Affected rows: 0  Found rows: 1.661.102  Warnings: 0  Duration for 1 query: 0,000 sec. (+ 1,515 sec. network) */
SELECT LEFT(m.N_SERIE,3)
FROM movimentos m
INNER JOIN movimentos_tipos t ON t.NUMERO=m.TIPO
;
/* Affected rows: 0  Found rows: 1.661.102  Warnings: 0  Duration for 1 query: 0,000 sec. (+ 1,516 sec. network) */
SELECT LEFT(m.N_SERIE,3)
FROM movimentos m
INNER JOIN movimentos_tipos t ON t.NUMERO=m.TIPO
;

Retornar todos os dados do campo:

/* Affected rows: 0  Found rows: 1.661.102  Warnings: 0  Duration for 1 query: 0,000 sec. (+ 1,516 sec. network) */
SELECT m.N_SERIE
FROM movimentos m
INNER JOIN movimentos_tipos t ON t.NUMERO=m.TIPO
;
/* Affected rows: 0  Found rows: 1.661.102  Warnings: 0  Duration for 1 query: 0,000 sec. (+ 1,609 sec. network) */
SELECT m.N_SERIE
FROM movimentos m
INNER JOIN movimentos_tipos t ON t.NUMERO=m.TIPO
;
/* Affected rows: 0  Found rows: 1.661.102  Warnings: 0  Duration for 1 query: 0,000 sec. (+ 1,609 sec. network) */
SELECT m.N_SERIE
FROM movimentos m
INNER JOIN movimentos_tipos t ON t.NUMERO=m.TIPO
;
/* Affected rows: 0  Found rows: 1.661.102  Warnings: 0  Duration for 1 query: 0,000 sec. (+ 1,610 sec. network) */

por **JoséQuintas** » 11 Dez 2019 08:39

/* Affected rows: 0 Found rows: 1.661.102 Warnings: 0 Duration for 1 query: 0,000 sec. (+ 1,593 sec. network) */
/* Affected rows: 0 Found rows: 1.661.102 Warnings: 0 Duration for 1 query: 0,000 sec. (+ 1,516 sec. network) */

Não entendi porque somente em um deles mostra 15 milésimos de segundo pro comando.

/* Affected rows: 0 Found rows: 1.661.102 Warnings: 0 Duration for 1 query: 0,015 sec. (+ 1,578 sec. network) */

Tá aí uma boa comparação com DBF
Processou 1.6 milhões de registros, trouxe 1.6 milhões de séries, e demorou 1.5 segundos pela rede.

Pra quem tem dúvida:
1.6 milhões x 3 caracteres x 8 bits = 38.4Mb... numa rede de 100Mb.... 1.5 segundos poderia até ser considerado demorado.

Agora vai processar 1.6 milhões de registros com DBF pra ver o que acontece.... nem faz diferença se é 1 caractere ou o registro inteiro...

E sem filtro, se trouxer só uma parte então... mais rápido ainda.

por **susviela@bol.com.br** » 11 Dez 2019 09:38

tonicm escreveu:Tá aí uma boa comparação com DBF
Processou 1.6 milhões de registros, trouxe 1.6 milhões de séries, e demorou 1.5 segundos pela rede.

Pra quem tem dúvida:
1.6 milhões x 3 caracteres x 8 bits = 38.4Mb... numa rede de 100Mb.... 1.5 segundos poderia até ser considerado demorado.

Agora vai processar 1.6 milhões de registros com DBF pra ver o que acontece.... nem faz diferença se é 1 caractere ou o registro inteiro...

E sem filtro, se trouxer só uma parte então... mais rápido ainda.

Opa ........
Mas ai a tua comparação está meia injusta, esse processo em um SGBD (todos os índices, tabelas referênciadas, integridade referencial, usuário, permissões , e Tigers estão ativos e em processamento )

por **JoséQuintas** » 11 Dez 2019 10:50

susviela@bol.com.br escreveu:Mas ai a tua comparação está meia injusta, esse processo em um SGBD

Não está não.
O objetivo é justamente chamar a atenção para a diferença do uso da rede.

Na prática... é pior... esqueci desta parte:
Vamos considerar 10 terminais emitindo um relatório...
Num relatório de 15 minutos em DBF, os 10 terminais vão estar usando a rede durante os 15 minutos, consultando até o que não interessa, e um atrasando o outro.
Em SQL vai levar esses 1.5 segundos... significa que a rede vai ficar mais de 14 minutos totalmente livre, aguardando mais comandos SQL.

Quem está online