[Cascavel-pm] Perl e Oracle

[Luis Campos de Carvalho]

Alceu R. de Freitas Jr. wrote:
> Olá pra todos,
> 
> Essa aqui vai para quem usa a dobradinha Perl+Oracle
> (o Le Champs deve ser um deles): 

   Desculpe desapontá-lo, Alceu, mas aqui o pessoal não usa Oracle... 
eles acham que não vale à pena, são representantes de um banco de dados 
chamado D3, da www.rainingdata.com, que eles pensam ser melhor... eu 
acabo usando MySQL para tudo, ou quase tudo...

   Se eu pudesse escolher, usaria PostgreSQL, que é quase tão bom quanto 
Oracle, mas melhor: é gratis... mas vamos voltar à vaca-fria:

> (...) para carregar dados
 > numa tabela, o que apresenta performance melhor: usar
> store procedures do Oracle ou script em Perl usando o
> módulo DBI? Considerem arquivos texto com campos
> delimitados por tamanho e arquivos xml.
> 

   # -- perl --
   use Verbose;
   __END__

   Precisamos fazer uma distinção.
   Você está falando de carregar dados usando que tipo de fonte de dados?

   (1) Se estiver pensando em gerar dados, ou carregar de um backup ou 
dump de dados "estrangeiro" (possivelmente de outro banco de dados 
não-oracle), a melhor forma é usar o DataLoader da própria Oracle. 
Pergunte ao seu DBA.

   (2) Se estiver pensando em dados de produção (um conjunto de dados 
que você não pode ter todo junto em um dado momento, como um cadastro 
que cada usuário preenche ao entrar no sistema), ou alguma outra forma 
de geração de dados incremental, a melhor forma de inserir dados é... 
Perl, é claro! =-] Por quê? Simples: ao usar Perl, o DBI gera 
diretamente um query INSERT para o RDBMS, e não precisa esperar carga e 
copilação de rotinas (ou acesso à memória para obter as rotinas), nem 
precisa esperar as rotinas rodarem para ter os dados em tabelas.

   Agora a escolha é sua: carga de dados estáticos (1) ou armazenamento 
de informações obtidas durante o tempo de produção, dinâmicamente(2)?

   --------------------------------------------------------------

   Sob o ponto de vista da engenharia de software, existem duas 
vertentes interessantes sobre este problema: a primeira (a) diz que você 
deve concentrar toda a inteligência da sua aplicação no seu sistema (e 
não no banco de dados). Isto obviamente fala contra Stored Procedures e 
coisas correlatas. A segunda (b) diz que o sistema deve ser dividido e 
que cada pedaço deve lidar apenas com informações relacionadas com ele 
(e assim, tudo o que estiver ligado com a integridade dos dados mantidos 
no RDBMS deveria estar implementado em Stored Procedures).

   Na minha opinião, você pode pensar nisso tudo conjugado:

   É bom para o seu sistema aceitar esta (a) ou aquela (b) aproximação 
para resolver o problema? O que você faz hoje? Se faz (a), não pode 
pensar em fazer (b) e vice-versa. Caso contrário, você criará um 
"pesadelo de manutenção" (Maintenance Nightmare - TM ) sem sombra de dúvida.

   Responder à estas perguntas podem ajudar você a escolher entre carga 
de dados estáticos ou armazenamento de informações obtidas durante o 
tempo de produção, dinâmicamente, que eu citei mais para cima...

   Espero que, além de verborrágico, eu tenha sido útil... =-]
-- 
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
   Luis Campos de Carvalho is Computer Scientist,
   PerlMonk [SiteDocClan], Cascavel-pm Moderator,
   Unix Sys Admin && Certified Oracle DBA
   http://br.geocities.com/monsieur_champs/
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=