Envio tarde, mas pode valer... Para realizar a cópia do arquivo entre diretórios/maquinas use compressão de arquivos (em java.util.zip), tem vários exemplos na internet.
Para ler o arquivo use SAX, que irá disparar um evento para cada tag/entity/comentario/pi/etc. e ai pode fazer o que quiser com essa informação. E não precisa armazenar toda a estrutura na memória (como DOM). ][s Claudio Miranda [EMAIL PROTECTED] escreveu, On 20/1/2003 09:32:
Rodrigo, valeu a dica. Eu estava imaginando que isso seria um empecilho
mesmo para um desenvolvimento em XML para arquivos TXT que já são muito
grandes.
Mas eu imagino que para os arquivos de pequeno porte talvez a coisa seja
viável, mesmo porque eu estou pensando em reusabilidade, portabilidade e
transações também. E creio que a performace deste sistema poderia melhorar
consideravelmente tendo em vista que não gastaria processamento com
abertura, leitura e processamento de cada linha de arquivo. O que vc acha ?
Nós aqui na Secretaria de Fazenda de MT estamos migrando tudo para JAVA e
Oracle.
Carlos
***********************************************
Carlos Santiago
[EMAIL PROTECTED]
Programador JAVA
Equipe de Implementação - SAGETI
Secretaria de Estado de Fazenda - MT
***********************************************
Rodrigo Rodrigues <rodrigo2naomi@ya Para: [EMAIL PROTECTED] hoo.com.br> cc: Assunto: Re: [java-list] JAVA e XML 19/01/2003 17:22 Favor responder a java-list
Boa tarde,
Vou responder por experiencia propria,
Tambem estou desenvolvendo um sistema de ETL (Extract
Transform e Load).
Meus arquivos tambem sao txt e provem de um ERP SAP.
Tem em torno de 150 000 linhas.
Eh totalmente descartada a utilizacao de XML, os
arquivos no minimo quadruplicam seu tamanho. O XML eh
mais adequado para transacoes, exchange e coisas do
tipo nao para carga de dados.
Soh por curiosidade qual o seu banco de dados, se for
Oracle voce pode tratar os txt´s por pl/sql, tenho
exemplos se precisar.
Temais.
--- [EMAIL PROTECTED] escreveu: > Gostaria de
colocar uma questão para a galera da
lista. Estou num projeto que manipula conteúdo de arquivos TXT e os grava num banco de dados. Até aí, sem problemas e nem novidades. A questão é que estes conteúdos são disponibilisados em linhas, minha aplicação lê cada uma destas linhas e as sub-divide em subStrings, e cada subString é uma informação que deve ser gravada em banco. Exemplo de uma linha deste arquivo: 5002951224000104131858602 20020625MT01UN194946163000000000130000000000013000000000000221000000000000000000000000001700NTrecho de código de processamento desta linha: (...) tipo = (linha.substring(0, 2)); cpfCnpj = linha.substring(2, 16).trim(); cfop = Integer.parseInt(linha.substring(53, 56).trim()); inscEstd = (linha.substring(16, 30).trim()); (...) Estas variáveis são gravadas no banco. Como disse, até aí sem problema. Mas existem arquivos cujo tamanho variam entre 40 e 100MB com cerca de 80mil a 840mil linhas, e cada uma destas linhas deve ser lida e processada. Como eu uso File para poder ler estes arquivos o consumo de memória é alto, pois estes arquivos são carregados na memória até o fim de seu processamento e os lotes de arquivos são da ordem de 2000 a 5000 arquivos. O que não é problema, a princípio, para os servers que temos aqui. O problema, na minha opinião e gostaria de poder ler a de vcs, é que se ouver uma mudança no padrão do tamanho da linha ou algum dado fora de lugar o processamento desta linha fica comprometido. Ou no caso concreto onde a variável cfop (do exemplo acima) não terá mais tamanho 3, passando a ter tamanho 4, isso faz com que eu tenha que mudar todas as outras "coordenadas" de varáveis, para poder pegar a informação correta. A minha idéia era a de acabar com esse lance de ter que ler linha a linha e sub-dividi-lás em subStrings. Poderia ter um arquivo XML parecido com este trecho: <tipo>50</tipo> <cpfCnpj>02951224000104</cpjCnpj> <cfop>616</cfop> <inscEstd>131858602</inscEstd> e assim por diante. Desta forma poderia acessar diretamente a informação que desejo. Claro que devemos fazer uma DTD para estes arquivos, pois cada <tipo> de linha tem a sua particularidade, mas isso também não seria problema. Bem, se transformar as linhas do arquivo TXT em tags de arquivos XML não é o problema, porque a questão ? Bem, se um arquivo texto, que só tem caracteres ANSI pode chegar a ter 100MB como ficará um arquivo XML com um monte de tags ? Muito maior que um arquivo TXT ! Mas eu acho que a vantagem seria a seguinte (gostaria que alguém me confirmasse): 1) Apesar do arquivo ser maior em MB as informações estarão dispostas de forma ordenada e se um campo mudar de tamanho não seria necessário mudar o processamento as outras variáveis. 2) Mesmo sendo maior em MB isso não acarretaria grandes transtornos de uso de memória tendo em vista que não usaria File para ler o arquivos, e depois cada linha do arquivo. Usando a API XML de JAVA (um parser) o mesmo carregaria na memória apenas a estrutura DOM do documento e isso é mais leve do que o arquivo como um todo. Posso usar esta estrutura para manipular as informações do arquivo. 3) Ganharia em velocidade de processamento, pois poderia acessar diretamente as informações desejadas e não ter que ficar "picando" linha a linha para separar a informação desejada, lembrando que tem arquivo com mais de 800mil linhas ! A galera que trabalha com arquitetura/projeto poderia opinar sobre esta possibilidade ? Tem alguém na lista que já implementou JAVA com XML pra valer ? Alguém sabe de padrões para JAVA com XML ? Abraço Carlos *********************************************** Carlos Santiago [EMAIL PROTECTED] Programador JAVA Equipe de Implementação - SAGETI Secretaria de Estado de Fazenda - MT ***********************************************
------------------------------ LISTA SOUJAVA ---------------------------- http://www.soujava.org.br - Sociedade de Usuários Java da Sucesu-SP dúvidas mais comuns: http://www.soujava.org.br/faq.htm
regras da lista: http://www.soujava.org.br/regras.htm
historico: http://www.mail-archive.com/java-list%40soujava.org.br
para sair da lista: envie email para [EMAIL PROTECTED] -------------------------------------------------------------------------
