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