Página 1 de 1
Trazendo string parcial
Enviado: 20 Nov 2019 09:43
por JoséQuintas
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?
Trazendo string parcial
Enviado: 20 Nov 2019 13:14
por sygecom
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.
Trazendo string parcial
Enviado: 20 Nov 2019 19:32
por tonicm
Sim, também uso assim.
Inclusive quando são dados de diversos campos, uso:
SELECT CONCAT(NUMERO, ' - ', REFERENCIA) AS Nome_Artigo
Trazendo string parcial
Enviado: 20 Nov 2019 20:39
por JoséQuintas
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).
Trazendo string parcial
Enviado: 10 Dez 2019 20:48
por alaminojunior
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 !
Trazendo string parcial
Enviado: 11 Dez 2019 08:06
por tonicm
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:
Código: Selecionar todos
/* 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:
Código: Selecionar todos
/* 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) */
Trazendo string parcial
Enviado: 11 Dez 2019 08:39
por JoséQuintas
/* 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.
Trazendo string parcial
Enviado: 11 Dez 2019 09:38
por susviela@bol.com.br
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 )
Trazendo string parcial
Enviado: 11 Dez 2019 10:50
por JoséQuintas
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.