Opa, o assunto está esquentando!!! 2006/11/28, wallace reis <[EMAIL PROTECTED]>: > On 11/25/06, Fabio Telles Rodriguez <[EMAIL PROTECTED]> wrote: > > > A idéia e debater sobre a concentração de inteligência da aplicação > > dentro do banco de dados. Gostaria de saber a opinião das pessoas da > > lista sobre o assunto, uma vez que acredito ser um assunto polêmico. > > > Muito bom artigo Fábio. Parabéns! > Comentando.... > Você comentou bem sobre o desenvolvimento em camadas. Posso falar da minha > experiência nisto. Nós desenvolvemos o sistema de informação que concentra > os serviços disponibilizados pelo núcleo, em Perl usando um módulo de > interface com o PgSQL chamado DBIx::Class e um módulo ORM chamado > DBIx::Class::Schema::Loader, usamos tbm o framework MVC Catalyst. Realmente > a preocupação com qual banco utilizar fazendo uso deste módulos é quase > zero. O módulo Schema::Loader msm, traduz as tabelas do banco em classes e > já define métodos de acesso para os campos das tabelas. E o DBIx::Class > provê métodos descritivos que já montam o SQL referentes às instruções de > SELECT, INSERT, DELETE e UPDATE, desde as mais complexas a outras mais > simples. Porém, ainda assim, temos algumas funções em PL: Perl, PgSQL. Como > por exemplo para criar números de acessão alfanuméricos seqüênciais. Mas > nada impediria que isto fosse feito na aplicação. Como vc mesmo disse, não > existe uma regra sobre em qual camada colocar as regras de negócio. > Em relação as brechas que vc disse existir nas camadas de abstração, eu > particularmente ainda não encontrei nenhuma.
PERL é realmente fantástico! PL/Perl também! DBI-Link então... Que eu me lembre, ao usar o DBI do PERL, você também pode enviar comandos tradicionais ao SGDB, para utilizar recursos específicos. Lembro uma vez de ter conversado bastante com o Mago sobre isto. Mas é verdade que a utilidade disto é restrita para situações muito específicas. Não conheço o suficiente de PERL para opinar aqui, mas pelo que eu lembre existem brechas... estou equivocado? > As funcionalidades que vc citou > (prover auditabilidade, gerar logs e realizar a carga de dados complexos), > acredito que estas não sejam operações requisitadas no desenvolvimento do > código de uma aplicação. Aplicações financeiras exigem logs muito bem elaborados, por exemplo. > São feitas geralmente em scripts batch. E mais, o > DBIx::Class tem uma váriavel de ambiente que pode ser setada para prover o > log das operações realizadas no SGBD. > Quanto ao processamento de longas transações, isto varia de sistema para > sistema. Pode, por exemplo, haver necessidade de que seja executado um fluxo > de trabalho que possa conter processos externos à aplicação que estão > localizados em um servidor diferente do SGBD, como é nosso caso aqui, e > mais, possuem uma lista individual imensa de parâmetros que precisam ser > customizados e validados para cada usuário. É um caso especifico que não > permite a criação de uma função em PL para executar este fluxo de trabalho > dados seus requisitos. É verdade, existem vários casos em que o SGDB não é um bom local para isso. Mas para processar uma folha de pagamento de 10 mil funcionários... pode ser uma boa!!! Realmente cada caso é um caso! Mas ainda fico imaginando que se as ferramentas de abstração fossem tão eficientes, porque é que as pessoas se debatem tanto entre a escolha de um Oracle, PostgreSQL ou MySQL? > > Bom, é isto. Enfim, parabéns pelo artigo. Obrigado pelos comentários.... meu intuito foi justamente o de coletar novas opiniões sobre o assunto... > wallace reis []s Fábio Telles -- site: http://www.midstorm.org/~telles/ e-mail: [EMAIL PROTECTED] jabber: [EMAIL PROTECTED] sip:[EMAIL PROTECTED] _______________________________________________ Grupo de Usuários do PostgreSQL no Brasil Antes de perguntar consulte o manual http://pgdocptbr.sourceforge.net/ Para editar suas opções ou sair da lista acesse a página da lista em: http://pgfoundry.org/mailman/listinfo/brasil-usuarios
