Marcelo wrote: > Nem precisa estar trabalhando com delphi nem qualquer programa, > trabalhe diretamente no access que vc vai notar a mesma coisa, de um > bd de 500k ele pula sem mais nem menos pra 10M.... pra reduzir > novamente eu importava todas as tabelas para outro bd , nos xixos da > vida.... valeus
O re-uso de páginas numa base de dados é comum. Muitas pessoas questionam-se porque é que a base cresce e não 'mingua'. Mas tudo tem uma razão. :-) Passo a rescrever um mail que enviei para outra lista, com uma linguagem muito simplista, mas que revela porque este "fenómeno" acontece. O assunto, mas não sobre o Access - sobre o Firebird. ---------------- Em bases de dados, a escrita em disco é uma operação "cara", a ser evitada. Imagina uma base Firebird como um livro. Um livro tem várias páginas. As páginas podem estar limpas ou escritas. Se você apaga dados na base, o Firebird marca as páginas como "Limpas". Da proxima vez que você escrever algo, ele vai usar essas páginas. Se todas as paginas estiverem escritas, aí ele sai para a rua e compra mais papel. Mas como o objectivo é ser economico, ele usa e re-usa as paginas sempre que pode. A unica forma de fazer o Firebird libertar as folhas é re-criar a base, com um backup/restore. Aí ele parte do principio que é um novo livro, logo compra apenas o papel necessário. --------------- Complementando: No Firebird, e devido ao seu uso de transacções ser bastante diferente do Access, eu até acho que este iria crescer muito mais que uma base Access, se fossem efectuadas as mesmas operações. O Firebird usa vários tipos de página para diferentes tipos de informação: dados vão para uma página, indices para outra, blobs para outra, etc. O aumento de tamanho do ficheiro Firebird está muito relacionado com o tamanho de página. Ao abrir uma transacção, e até esta ser commit ou rollback, a informação é escrita no disco. Não interessa que seja uma transacção apenas de leitura (um simples select), o que interessa é o seu isolamento de outras transacções. A base pode assim "crescer de tamanho" devido a um simples select. Quando se procede a uma operação do tipo: DELETE FROM TABELA; COMMIT; o que o Firebird faz é bem simples: pega um 'flag' em cada registo, que indica o estado do registo, e modifica de 'On' para 'Deleted'. Os dados ficam na mesma na base, intactos. Assim, é possivel e relativamente fácil pegar nesta base de dados neste estado e recuperar toda a tabela. [Enfase para 'neste estado'. Se o utilizador fizer SELECT COUNT(*) FROM TABELA; COMMIT; no momento seguinte, os dados ficarão quase sem recuperação. Mas isso é outra historia...] Finalmente: com um hard disk de 120Gb a custar cerca de 50 dolares, quem se preocupa em finais de 2004 com detalhes deste tipo? :-) Artur Que hoje já escreveu demais. :-) -- <<<<< FAVOR REMOVER ESTA PARTE AO RESPONDER ESTA MENSAGEM >>>>> Para ver as mensagens antigas, acesse: http://br.groups.yahoo.com/group/delphi-br/messages Para falar com o moderador, envie um e-mail para: [EMAIL PROTECTED] ou [EMAIL PROTECTED] Links do Yahoo! Grupos <*> Para visitar o site do seu grupo na web, acesse: http://br.groups.yahoo.com/group/delphi-br/ <*> Para sair deste grupo, envie um e-mail para: [EMAIL PROTECTED] <*> O uso que você faz do Yahoo! Grupos está sujeito aos: http://br.yahoo.com/info/utos.html
