Re: [Cascavel-pm] performance de BD com registros contendo espaços (OFF-TOPIC)

Marco A P D'Andrade mdacwb em gmail.com
Quinta Fevereiro 9 11:49:25 PST 2006


Alceu,



Eu gostaria de saber se alguém já teve experiência de
> ter que lidar com dados dessa forma em um BD:
>
> select a.nome, c.razao_social
> from cliente a, detalhes b
> where a.nome = 'JOSE      ',
> and b.codigo = '123     ',
> and b.xyz = '    123'



Não sei precisar o quanto poderia haver de perda de performance, mas com
certeza isto atrapalha na hora de tratar as querys, entendo que isto vai
depender do comportamento do banco quando for comparar "Perl Monks" com
"Perl Monks    "....

Passei por uma situacao parecida, nao me lembro se foi com oracle ou
mysql... para facilitar minha vida usei a opção ChopBlanks no connect ...

Um outro caso em que tive experiencia foi um portal de uma promoção que
tivemos aqui (21nacopa), onde a simples definição erronea de querys vs
tabela era suficiente para manter varias pessoas envolvidas (ou perdidas)
com o desempenho do portal...

Os campos eram string, apesar de ser uma chave que continha somente numeros
(como em seu exemplo), e a query informava valor numerico. Esta conversao de
tipo forcava uma execucao muito precaria...


Essa query é criada dinamicamente, portanto os dados
> são recuperados da base (que está um caco, como podem
> ver). Além de problemas óbvios de correr o risco de
> não encontrar algo, quanto espaços podem causar de
> perda de performance em queries parecidades com esta
> (ou seja, sem usar LIKE)? Isso é estritamente
> dependente do BD ou na teoria é ruim para qualquer um?


Isto quem vai poder lhe responder é o Champs... o DBA de plantao  :D

Não tenho acesso aos dados para corrigir isso, mas
> seria interessante levantar a perda de performance,
> caso ela realmente exista e seja significante.
>

Se nao pode resolver... avalie o que o ChopBlanks pode ajudar, e bola para a
frente ;)


Espero nao ter confundido muito mais as coisas ;)

Sds,
Marco Antonio
-------------- Próxima Parte ----------
Um anexo em HTML foi limpo...
URL: http://mail.pm.org/pipermail/cascavel-pm/attachments/20060209/e11f7fc4/attachment.html


Mais detalhes sobre a lista de discussão Cascavel-pm