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