[Cascavel-pm] Arquivo configuracao a parte

Nilson Santos Figueiredo Junior acid06 em gmail.com
Terça Agosto 15 10:18:40 PDT 2006


On 8/15/06, Alceu R. de Freitas Jr. <glasswalk3r em yahoo.com.br> wrote:
> Filosoficamente sim. Mas quando você precisar espremer
> seu código para ele rodar mais rápido a coisa muda de
> lado.

Quando você precisar espremer seu código pra rodar mais rápido, o
DBIx::Class te dá as ferramentas para descer até qualquer nível do
processo de mapeamento objeto relacional. Desde a geração de SQL até
às várias etapas da criação dos objetos propriamente ditos. Na
verdade, o DBIx::Class algumas vezes faz com que você tenha bem menos
trabalho para ter ganhos de performance.

Um exemplo disso é que ele é inteligente e só busca no banco de dados
se você realmente precisar dos dados de um resultset. Ou seja, você
pode criar o resultset, especificar as condição de busca (i.e. "WHERE
x == y") mas se você nunca utilizar os dados daquele resultset, ele
nunca vai buscar. Isso é uma facilidade tremenda quando você está
trabalhando em um modelo MVC. Você pode ter controladores genéricos
que provêm várias fontes de dados para a sua View e no final das
contas a View só usa o que precisa. O melhor de tudo é que, quando ele
fizer a query, ele ainda vai fazer da forma mais eficiente possível
para as relações entre tabelas que você especificou.

> 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 DBIx::Class não se restringe a ANSI SQL. Ele tem um driver para cada
banco de dados que implementa a melhor forma possível para aquele
banco de dados. E se você quiser cair para SQL, você pode fazer
queries inteiras em SQL ou apenas especificar algumas condições em SQL
puro e o resto na sintaxe do SQL::Abstract. E mesmo assim ele sabe
como criar os objetos a partir disso tudo. Você pode utilizar funções
do banco de dados, operadores não-padrão (e.g. "  =* para outer joins
em MSSQL "), da forma que quiser. Só não é algo recomendado uma vez
que são recursos não-portáveis.

> 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?

Porque mata a portabilidade? Não entendi esse argumento. O seu código
em Perl continua sendo portável. O código no back-end de dados deverá
ser adaptado à plataforma.

Uma view em MySQL tem performance equivalente à de um select em uma
tabela com a vantagem de que as colunas da view que são mais
"complexas" de serem calculadas (e.g. são resultados de uma função
complexa) só são calculadas se elas estão especificadas como uma
coluna do select. Acredito que todos os RDBMS sejam mais ou menos
assim, também.

A view é criada a partir de SQL arbitrário então você pode utilizar
quaisquer recursos de performance / otimizações que desejar e pra sua
aplicação aquilo aparece simplesmente como uma tabela.

> 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.

Alguém tem que construir os ORMs, certo?

E eventualmente você realmente precisa de utilizar uma linha de SQL.
Por exemplo, uma limitação atual do DBIx::Class é que ele não possui
uma sintaxe abstrata para subselects (isso é algo planejado para a
versão 0.08000). Nesse caso, você sempre tem que utilizar uma linha de
SQL puro na sua query (claro que a solução ideal seria a criação de
uma view, mas às vezes você realmente só está utilizando aquilo em um
único lugar específico da sua aplicação e uma view é overkill).

Mas apesar de não escrever as queries em SQL ser um grande benefício,
na minha opinião o maior benefício é ter todos os seus dados como
objetos que podem ser facilmente modificados, extendidos e atualizados
e tudo sendo refletido no banco de dados sem esforços.

Uma coisa bastante legal é que com o DBIx::Class fica fácil de você
implementar trasações que são consistentes ao longo de back-ends
diferentes porque o que determina as transações é um bloco de código e
qualquer exceção não-tratada dentro desse bloco de código significa um
rollback na(s) transação(ões). Ou seja: operações até certo ponto
comuns como atualizar uma tabela e depois copiar um arquivo de um
lugar pra outro pode ser encapsuladas numa trasação e caso ocorra um
erro na cópia do arquivo, ocorrerá um rollback no banco de dados.

-Nilson Santos F. Jr.


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