Vale ressaltar que o DB2 Express-C 9 tb tem uma ferramenta de importação de
arquivo em diversos formatos e oferece uma ferramenta gráfica junto com o SGBD
para construir o comando de importação, definir o formato (algo parecido ao q
se faz no CTL do SQLLoader), que facilita muito o trabalho. Por experiência
própria eu posso dizer que escrever a carga nessa ferramenta é bem mais rápido
que pelo SQLLoader. Quanto à performance ele não deixou nem um pouco a desejar
no meu P4 com 512 de RAM. E no final ainda posso agendar a carga (aquilo que
faria pelo CRON ou pelo Jobs Scheduler), definindo pra rodar imediatamente, uma
única vez ou periodicamente (em qualquer periodicidade).
Além do mais existe uma característica que eu achava o máximo no ORACLE 10 G
mas quando descobri como o DB2 Express-C 9 implementa aí sim eu gostei ainda
mais do comando. Se trata do MERGE que pode ser usado em processo ETL,
equalização de dados em tabelas, etc. No ORACLE se acontecer algum erro em uma
linha vc perde todo o teu comando MERGE. Já em DB2 vc pode executar da mesma
maneira que no ORACLE ou se preferir poderá ignorar o erro (ou mesmo gravar a
linha e a mensagem de erro em uma tabela de log) e continuar o processo de
carga/equalização por MERGE normalmente. Já procurei implementar isso em ORACLE
mas ainda não consegui. Se alguém souber como se faz isso em ORACLE...fique à
vontade pra me dizer...
Fabio Telles <[EMAIL PROTECTED]> escreveu: Em 05/09/07, Bruno Almeida do Lago
escreveu:
> Fábio,
>
> > SQLLoader é uma ferramenta para importação de grandes volumes de dados em
> > arquivos texto em diversos formatos. E uma ferramenta realmente robusta e
> > flexível que pode lhe ajudar a fazer ETL, migrar dados de plataformas
> > distintas, etc.
>
> Em alguns testes que realizei o COPY do PostgreSQL se comportou tão bem
> quanto o SQLLoader... Você enxerga alguma grande diferença a ponto de
> considerar o SQLLoader uma vantagem?
Sim, vide os comentários em
http://www.midstorm.org/~telles/2007/08/30/16-caracteristicas-do-oracle-que-fazem-falta-no-postgresql
>
> > Fine -Grained Access, é uma ferramenta do Oracle que permite o acesso a
> > determinadas linhas de uma tebela de acordo com o perfil do usuário
> > conectado. Este é um recurso interessante que em aplicações corporativas
> > podem ajudar um bocado.
>
> Um DBA consiente entende que um dia a aplicação está rodando em um SGBD e no
> outro dia em outro (preço, recursos, licenças). Por que não criar uma view e
> dar os grants necessários para o usuário em questão?
>
> Conheço uma porrada de empresa que começou a utilizar os recursos
> específicos de um gerenciador e hoje está passando por um verdadeiro
> inferno.
>
É verdade. Por um lado devemos evitar funcionalidades muito
mirabolantes, por outro lado, há momentos em que escolhemos um SGDB
exatamente por causa delas. Não vou defender muito o FGA aqui não. Não
acho que é algo tão importante, mas a idéia não deixa de ser
interessante. No entanto, em algumas situações, em aplicações
específicas poderia ser um diferencial.
> > O Jobs Scheduler é ferramentas do Oracle que permite o disparo de ações
> > específicas através do agendamento em horário específico, se repetindo ou
> > não em intervalos programados. Muitas pessoas resolvem esta ausência
> > utilizando o CRON do Linux, mas o Job Scheduler tem uma série de
> > funcionalidades interessantes, além de permitir tratar tudo via SQL.
>
> Gostaria de entender melhor as "funcionalidades interessantes", pq só me
> f*(@#&$ qdo uso o scheduler do Oracle. Quantas vezes esse cara já deixou de
> rodar um JOB e nem deu satisfação do motivo... Fora que a interface com ele
> (dbms.scheduler) é uma tranqueira, enquanto um VI no crontab é bem mais
> tranquilo...
>
Bom, eu particularmente gosto de trabalhar via SQL. Existem rotinas
que são mais complexas que uma simples linha no crontab. Existem casos
em que eu preciso verificar algumas condições em tabelas para decidir
o que fazer de madrugada. Em importações e exportações de dados
complexos, com validação, auditabilidade, etc, etc. Um pouco de PERL
poderia me resolver o problema no PostgreSQL, mas aí eu já estou
introduzindo a dependência de uma nova linguagem para o meu time de
DBAs. Particularmente eu gosto de trabalhar direto dentro do SGDB. Não
tive os problemas com o Scheduler que você mencionou, ele me parece
mais fácil de flexível que os Jobs da versão 9i. Não sei como está
isso no 11g, não tive tempo de testar ainda.
No entanto, realmente o Oracle começou a abusar dos seus packages. A
sintaxe começou a ficar um pouco chata mesmo. Acho que isso só tende a
piorar, uma vez que as novas funcionalidades do Oracle surgem cada vez
mais a partir dos Packages. Mas é melhor não cantar muita vitória. Eu
não me surpreenderia se isso começar a acontecer no PostgreSQL daqui a
alguns anos. É claro que eu confio no bom senso do time de
desenvolvedores do PostgreSQL, para não deixar a coisa degringolar
demais.
>
> Enfim, só os meus 2 centavos de desabafo.
>
Comentários são muito bem vindos. Agradeço a atenção.
[]s
Fábio Telles
--
blog: http://www.midstorm.org/~telles/
e-mail / jabber: [EMAIL PROTECTED]
_______________________________________________
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Flickr agora em português. Você clica, todo mundo vê. Saiba mais._______________________________________________
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
