[]s
At 17:52 19/1/2003 -0300, you wrote:
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 20020625MT01UN
>
194946163000000000130000000000013000000000000221000000000000000000000000001700N
>
> Trecho 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]
>
-------------------------------------------------------------------------
>
_______________________________________________________________________
Busca Yahoo!
O melhor lugar para encontrar tudo o que voc� procura na Internet
http://br.busca.yahoo.com/
------------------------------ 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]
-------------------------------------------------------------------------
Esta mensagem foi verificada pelo E-mail Protegido Terra.
Scan engine: VirusScan / Atualizado em 15/01/2003 / Vers�o: 1.3.13
Proteja o seu e-mail Terra: http://www.emailprotegido.terra.com.br/
----------- Herval Freire de A. J�nior ----------
----- mailto:[EMAIL PROTECTED] -------
--------- http://www.herval.hpg.com.br ----------
----------------- UIN: 2067270 ------------------
-------------------------------------------------
--[The adepts are everywhere... awake! v0.666a]--
-------------------------------------------------
"Erros graves: julgar-se mais do que se � e estimar-se menos do que se merece".
-- Goethe
