[Cascavel-pm] Arquivo configuracao a parte

[Luis Motta Campos]

Nilson Santos Figueiredo Junior wrote:
> On 8/15/06, Luis Motta Campos <monsieur_champs em yahoo.com.br> wrote:
>>   3. Views podem complicar muito a parada, especialmente no quesito
>> memória. Quando a performance não é tão importante quanto poder fazer
>> queries (sim, tem casos extremos de gente louca que não se incomoda em
>> levar 12 horas para fazer uma pergunta, desde que se consiga resposta)
>> views apenas atrapalham. Elas ocupam muito mais memória do computador, e
>> normalmente obrigam a múltiplas perguntas ao banco para resolver coisas
>> simples como um "SELECT id FROM that_view ORDER BY id DESC", já que tem
>> horas em que múltiplos result-sets intermediários serão criados no banco.
> 
> No MySQL, as views apresentam um comportamento "inteligente". Elas só
> buscam / calculam os campos que foram pedidos então esse tipo de
> problema não ocorre.
> 
> Não consegui entender o porquê do uso de memória supostamente
> aumentar. Suponho que talvez seja porque o RDBMS faz um cache da view.
> Mas isso, teoricamente, seria algo bom e não algo ruim.
> 
>>   Eu não acredito que exista qualquer coisa que se possa ofercer neste
>> campo. Toda vez que preciso construir queries dinamicamente, estou
>> perdendo tempo fazendo cálculos que um DBA ou Analista deveria ter feito
>> de cabeça antes da aplicação rodar. Isso quer dizer: eu repito
>> incansávelmente o trabalho de um DBA/Analista a cada nova pergunta que
>> vou fazer ao banco de dados, mesmo que a pergunta seja a mesma que eu
>> fiz 10min atrás.
> 
> Não é exatamente assim. Alguma parte do trabalho pode ficar em cache
> (e.g. prepare_cached() do próprio DBI). A construção do SQL a partir
> de uma sintaxe abstrata é um processo relativamente barato
> computacionalmente.
> 
> Como eu disse antes, a principal vantagem é você ter tudo como objetos
> e não a geração dinâmica de queries, apesar disso também ser uma
> grande coisa. Eu, como desenvolvedor, espero nunca ter que trabalhar
> em um lugar aonde eu dependa de um DBA para toda minha interação com o
> banco de dados. Portanto, ao utilizar algo como o DBIx::Class eu
> elimino essa necessidade de existir alguém que cuide desse trabalho e
> ganho mais liberdade.
> 
> Se eu não gostasse desse princípios eu, provavelmente, seria um
> desenvolvedor Java./
> 
>>   Não me parece que exista outra forma de usar bibliotecas de geração de
>> código SQL dinâmico, e esta, de uma forma muito geral e totalmente
>> independente de linguagem de programação, me parece muito cara para usar
>> em sistemas sérios ou que precisem aproveitar mais ou menos bem os
>> recursos de computação que têm à disposição.
> 
> Se você acha que esse tipo de coisa é inviável... bem... só no mundo
> Perl / Catalyst:
> 
>   http://dev.catalystframework.org/wiki/LiveApplications
> 
> Veja o "boom" do Ruby on Rails e outros frameworks como o Turbogears
> para Python e até mesmo o próprio Hibernate para Java e seus cases de
> sucesso na prática.
> 
> É claro que todas as facilidades ao desenvolvimento têm um custo
> computacional mais elevado. Contudo, a coisa se resume ao seguinte:
> 
>   - 1 GB de RAM custa 400 reais (jogando *muito* pra cima)
>   - 1 servidor Dell razoável custa tão pouco quanto 2800 reais
>   - 1 bom desenvolvedor custa no mínimo uns 3000 reais por mês
> 
> Isso são dados do Brasil. Expanda isso internacionalmente onde o
> hardware é ainda mais barato e os salários são bem mais altos e você
> verá como eficiência nesse sentido deixa de ser relevante no mundo
> atual.
> 
> Você deve ser preocupar com eficiência no sentido de usar algoritmos
> que não explodam exponencialmente. Mas algo O(n) ou O(2n) não é uma
> grande diferença prática pois são problemas solucionáveis simplesmente
> jogando mais hardware. Lembrando que na prática o custo de um mapeador
> objeto relacional otimizado em relação a queries pré-construídas não
> passa de uns 10-15% a mais, o resto do ganho de performance visto em
> benchmarks se deve ao fato de que o DBI "puro" não retorna objetos mas
> sim hashes ou arrays e se você não quer objetos realmente não deveria
> estar utilizando um mapeador *objeto*-relacional, mas se você fosse
> construir os objetos manualmente, provavelmente teria um desempenho
> ainda pior.
> 
> -Nilson Santos F. Jr.
> _______________________________________________
> Cascavel-pm mailing list
> Cascavel-pm em pm.org
> http://mail.pm.org/mailman/listinfo/cascavel-pm
> 

  Nilson, eu cansei.
  Este discurso está muito comprido e eu não tenho tempo para discutir.
  Preciso continuar otimizando meus queries de banco de dados.

  Putamplexos!
-- 
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
 Luis Motta Campos is Software Engineer, Oracle OCP/DBA, Un*x
 Sysadmin, Member of {Lisbon,São Paulo,Cascavel,Brasil,London}
 Perl Mongers and Perl Fanatic Evangelist
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=