[Cascavel-pm] Arquivo configuracao a parte

[Alceu R. de Freitas Jr.]

--- Nilson Santos Figueiredo Junior <acid06 em gmail.com>
escreveu:

> On 8/14/06, Luis Motta Campos
> <monsieur_champs em yahoo.com.br> wrote:
> >   Claro, e esquece que existe performance... ;-)
> tem poucas coisas com
> > performance tão porca como mapeamentos
> objeto-relacionais... :-/

> A primeira e mais relevante motivação para se usar
> um mapeamento
> objeto-relacional se resume ao seguinte: meu tempo
> vale mais que o
> tempo do computador.

Filosoficamente sim. Mas quando você precisar espremer
seu código para ele rodar mais rápido a coisa muda de
lado.

> O benefício mais óbivio é que sua aplicação se torna
> automaticamente
> portável para qualquer um dos bancos de dados
> suportados (todos os
> relevantes atualmente) sem se preocupar com
> reescritas de queries
> porque o MSSQL não usa pontos-e-vírgulas no final de
> queries ou coisas
> assim. Infelizmente, SQL não é universal e várias
> coisas cruciais
> (como pegar o ID de uma entrada que acabou de ser
> inserida) variam
> drásticamente de RDBMS para RDBMS e uma abstração é
> extremamente
> necessária.

Eu diria que é aí que o DBIx::Class e outros
mapeadores deixam de ser interessantes. Algumas vezes
o banco de dados lhe oferece soluções proprietárias
muito melhores em termos de facilidade de
implementação e performance do que ANSI SQL.

> O outro benefício é que o DBIx::Class faz com que
> suas entidades de
> dados sejam vistam como objetos em sua aplicação.

Isso é o mínimo esperado. Mas dá para fazer o mesmo se
você sair criando DAO's aos montes. Claro que dá mais
trabalho.

> Quando você
> tem queries "difíceis" de serem feitas utilizando o
> DBIC, isso é um
> forte indício de que você deveria ter criado uma
> View (ou stored
> procedures) em seu RDBMS para aquele conjunto de
> dados.

Mas aí você mata a portabilidade da aplicação. :-)
Eu não sei até que ponto uma view é útil em questão d
performance também... não sou um DBA. Alguém poderia
dar mais uns pitacos?

> Mas, hoje em dia,
> o DBIx::Class é razoavelmente bem documentado e a
> maioria poderia
> descobrir essas coisas sozinho. Mas caso ainda assim
> alguém possua
> dúvidas sobre o DBIx::Class (ou o Catalyst) ficarei
> feliz em tentar
> ajudar no que eu puder. Só não me peçam ajuda em SQL
> pois eu já estou
> quase esquecendo essa linguagem medonha. ;-)

Eu mesmo preciso testar esse camarada. Eu fugi desses
mapeadores (até dos implementados em Java) justamente
por esses problemas de performance (e até pelo
buzzword  que permeia os programadores dessa
linguagem). Só não me parece que o SQL vai sair de
campo tão cedo assim só por causa de ORMs.

[]'s



Alceu Rodrigues de Freitas Junior
--------------------------------------
glasswalk3r em yahoo.com.br
http://www.imortais.cjb.net
-----------------------------------------------------------------------
A well-used door needs no oil on its hinges.
A swift-flowing stream does not grow stagnant.
Neither sound nor thoughts can travel through a vacuum.
Software rots if not used.
These are great mysteries -- The Tao Of Programming, 5.1


		
_______________________________________________________ 
Novidade no Yahoo! Mail: receba alertas de novas mensagens no seu celular. Registre seu aparelho agora! 
http://br.mobile.yahoo.com/mailalertas/