Entao, Como tinha te dito. Na sexta passada comecei a fazer testes de stress com o meu sistema. Recebi um catalogo de produtos do SAP ERP com 50 000 linhas. Usando uma package Oracle li e escrevi numa tabela no meu banco tudo em menos de 2 minutos. Tambem, apos um tratamento dos dados, gerei um outro arquivo de saida txt com as 50 000 linhas em menos de 2 minutos. Com o Oracle temos a opcao de utilizar um outro utilitario chamado SQLLoader mas optei pela package UTL_FILE que me dah mais opcoes de tratamento de linha (como voce precisa, nao eh?).
Se precisar te mando uns exemplos. Por outro lado, Vamos supor que voce queira criar este seu mecanismo de leitura, escrita e esteja pensando em outras utilizacoes disto. Esteja pensando tambem em usar isto como um CASE para voce e sua empresa e que ainda sejam arquivos pequenos. Use mesmo o XML! Nao vou dizer que um minimo de hard code nao tive que fazer para a package UTL_FILE ler o TXT. Carlos, usando XML, TXT, sempre o arquivo serah aberto e as linhas interpretadas, apenas a maneira que isto serah feito que eh diferente com XML. Pensando no futuro e em reutilizacao crie a DTD, os XML�s que voce vai ter bons frutos. Nao querendo cair em contradicao, quando trabalhei com XML no Oracle tambem tive que usar a mesma package UTL_FILE. Se precisar tambem tenho exemplos da UTL_FILE com XML. Voce poderia me perguntar: Mas e o Java Rodrigo? Usei uma Java Stored Procedure para direcionar o arquivo do sistema operacional para ser interpretado pela package e nada mais. Da maneira que fiz ficou tudo dentro do Banco. Prefiro assim. Nao sei se me enrolei um pouco nas palavras... Rodrigo. Rodrigo. --- [EMAIL PROTECTED] escreveu: > > 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 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 > === message truncated === _______________________________________________________________________ Busca Yahoo! O servi�o de busca mais completo da Internet. O que voc� pensar o Yahoo! encontra. 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] -------------------------------------------------------------------------
