[firebase-br] RES: Banco Crescendo Rapidamente

[Evandro Borges]

Prezado Gladistone:
O que eu tentei explicar para o Diego Bulgarelli, foi extamente isto. Usar Update e Delete somente em último caso. Eu uso só quando alguém realmente erra um lançamento e não ha outra forma mesmo.
Com relação ao campo S ou N foi só uma opção que eu citei. Quando preciso usá-lo, crio uma tabela secundária e uso seu campo chave com foreignKey da tabela primária. Uso inner join e where  tabela2.campo='S'
Com relação a controle títulos,  Insiro um registro para a venda com valor positivo e registros dos pagamentos (caso seja mais de uma parcela) com sinal negativo. Faço select com group by e having sum(valor_da_fatura)<>0.
No início meu banco até triplicava de tamanho em uma semana, atualmente seu tamanho já esta bem controlado a mais de 5 anos.
Também aconselhei que nosso amigo, aquele que estava com problemas de crescimento no BD, estude bem e implemente todos os recurso e comandos disponíveis no SQL.
O Firebird é muito bom, não conheço outros (MySQL Postgree e etc); sou da época do DBASE e depois Paradox, quando comecei a utilizar Interbase/Firebird é que entendi o que é um Banco de dados.
Até o momento o único problema que enfrento no Firebird e sua lentidão quando estou em minha casa e preciso acessar os dados via VPN, fica muito lento. Já estive em vários Fóruns, implementei vários recursos e nada. Para verificar a velocidade de uma consulta via VPN, entro no IB expert e faço um select, os dados chegam até mim em pacotes de 500 registros a cada segundo.
Talvez se alguém puder me ajudar, meu sistema é em Delphi.


Evandro 

> Date: Tue, 5 Feb 2013 10:01:24 -0200
> From: gladiston em vidy.com.br
> To: lista em firebase.com.br
> Subject: Re: [firebase-br] RES: Banco Crescendo Rapidamente
> 
> Todo o lixo a que se refere provavelmente são as versões de registros. As
> mesmas são eliminadas através do backup e as páginas em branco são
> aproveitadas outra vez sempre que possível. Além disso, ter um campo de
> situação que muda de 'S' para 'N' faz criar mais uma versão de registro, e
> não faz parar de aumentar de tamanho (ao contrário), talvez sua situação só
> resolva nos casos onde o registro não caiba no tamanho de página
> (geralmente 4K), talvez você esteja passando por uma situação assim.
> 
> Para você entender melhor, recomendo que faça o seguinte experimento :
> Pegue a tabela maior que tiver e crie um campo para 'S' ou 'N'  - use
> char(1) e não use varchar. Então dê um update em todos eles (update tabela
> set campo='S').
> Depois exporte a tabela para um arquivo .sql, crie então um database novo
> de testes e execute o script alí.
> Desconecte-se e anote o tamanho da base.
> Conecte-se novamente e rode um update nessa tabela envolvendo todos os
> registros (update tabela set campo='N').
> Desconecte-se e anote o tamanho da base, provavelmente aumentou muito,
> claro que não dobra de tamanho, estamos falando de um char(1).
> Agora vem o pulo do gato, faça o backup, preferencialmente usando
> o utilitário gbak, mas pode ser via API tambem. Só não use alguma opção que
> faça manter o garbage - Alguns aplicativos vem com essa opção habilitada.
> Conecte-se novamente e rode um update nessa tabela envolvendo todos os
> registros, mas dessa vez ponha outro valor (update tabela set campo='S').
> Desconecte-se e anote o tamanho da base, quando você fez isso da primeira
> vez, o tamanho aumentou, mas dessa vez não aumentou, por que ?
> A razão é que o FB aproveita as páginas que houverem em branco sempre
> que possível, porque sempre que possível ? Não dá para garantir que seus
> updates tenham sempre o mesmo tamanho da página em branco, como as
> gravações novas não desejam fragmentar os seus dados em páginas
> geograficamente separados, essa nova gravação poderá preferir criar páginas
> novas garantido que esses dados sejam contíguos  Por isso o
> reaproveitamento nem sempre é 1 para 1.
> 
> Porque o FB mantém o garbage ? Simples, se houve algo catastrofico em sua
> base, ele se corrige sozinho restaurando a ultima versão valida de cada
> registro.
> 
> Se seu banco aumenta muito você tem de pedir ajuda de alguém experiente
> para entender o processo, uma orientação perita irá lhe conferir o que
> precisa.
> Por exemplo, os varchar são os verdadeiros fragmentadores de database, como
> seu tamanho pode variar de um registro para outro, nem sempre
> é previsível que um dado novo pode reaproveitar páginas em branco se a
> mesma não pode garantir que caberá na página ou se páginas contíguas serão
> usadas, além disso, varchars gigantes, por exemplo,  para conter um xml de
> NFe talvez use varchar(8192), qual o problema disso ? Num database que tem
> páginas de 4K (default),  fará com que quase sempre páginas novas sejam
> criadas e reaproveitar páginas só ocorrerá quando houver grande
> espaços contíguos na base, o que pode demorar e se houver muito update essa
> base explodirá de tamanho. Neste sentido é melhor usar MEMO´s e char
> simples e repudir varchar se sua preocupação for espaço.
> ______________________________________________
> FireBase-BR (www.firebase.com.br) - Hospedado em www.locador.com.br
> Para saber como gerenciar/excluir seu cadastro na lista, use: http://www.firebase.com.br/fb/artigo.php?id=1107
> Para consultar mensagens antigas: http://firebase.com.br/pesquisa