[Cascavel-pm] Arquivo configuracao a parte

[Nilson Santos Figueiredo Junior]

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.