PC Toledo

Tava lendo uma comparação, não falava sobre isso, mas serve pra isso.
Chamou a atenção esta parte:

buffer 65534: 10000 * 4 b == 32 kb/s | 8244 blocks/s
buffer 65534: 10000 * 8 b == 64 kb/s | 8298 blocks/s
buffer 65534: 10000 * 16 b == 126 kb/s | 8097 blocks/s
buffer 65534: 10000 * 32 b == 256 kb/s | 8203 blocks/s

Nessa rede, praticamente a velocidade EM BLOCOS é constante, mesmo o bloco chegando a 256kb/s ou 256.000 bytes.
Acontece que o DBF é lido POR REGISTRO, então o bloco vai usar um registro.

Ao usar DBF, vai precisar vários blocos pra emitir o relatório.
Ao usar cliente/servidor, de repente um único bloco já trás o relatório inteiro.

Então, uma coisa é o programa precisar ler um registro por vez para escolher o que vai usar.
Nisso o DBF já perde.

Outra coisa é que a comunicação cliente/servidor é um registro por vez, quando a capacidade de transferência é muito maior.

Confude, mas são duas coisas distintas. Talvez dê pra explicar melhor usando balde e água como exemplo.

A parte de lentidão 1:
O relatório vai trazer todos os baldes de água pra ver qual balde interessa. Vai trafegar baldes inúteis.

A parte de lentidão 2:
Os baldes conterão apenas um copo de água, mesmo tendo capacidade pra muita água.

Na hora de programar usando cliente/servidor, tem que pensar nessas duas coisas.
Por exemplo, um SET FILTER, vai ser mais rápido, porque vai usar "menos baldes".
Mas se fizer o SELECT trazendo tudo que interessa de uma vez, vai usar a capacidade máxima dos baldes, portanto menos baldes e mais rápido.

A rede de 1GB tem baldes maiores.
Por isso, pode até deixar o sistema um pouco mais rápido, mas não tanto, porque o conteúdo dos baldes continuará sendo um único registro.

Finalizando:
É por isso que um COPY é sempre mais rápido do que qualquer coisa.
E é por isso que DBF ficou meio que ultrapassado.
O Access até seria mais rápido, mas também deixou de ser opção, por ser frágil em rede igual DBF.

Nota: fiquei na dúvida, porque isso se refere a banco de dados. Por outro lado, muitos devem querer entender como acelerar o Harbour em banco de dados, e DBF é a base padrão do Harbour, e a mais usada.

Olá, bom dia Quintas.
Mas o que usar com o harbour então?
Eu acabei de migrar prá ele, modo console. A velocidade em geral já melhorou consideravelmente em relação ao Clipper+Blinker.
IDX ou CDX ajudaria ?

Olá Maurício Elias,

Vou me meter no assunto... Eu utilizo já há algum tempo a HMG 3.0.46, gerando sistemas em modo gráfico.

Mesmo quando meus sistemas eram em modo console, sempre notava a perda de velocidade na questão de acesso a .dbf's em rede. Mesmo tendo trocado os arquivos de índice de .NTX para os .CDX (que já dava uma pequena diferença no acesso).

Há pouco tempo mudei dos antigos .DBF para o MySql e vou te dizer... Foi uma diferença considerável ! Do tipo, para gerar um relatório em um cliente que tinha uma base grande de dados, um determinado relatório demorava em torno de 45 segundos (Servidor) e de 2 a 3 minutos em qualquer outro micro que estivesse na rede...

Claro, podemos considerar que, havendo uma rede montada de forma correta utilizando switch, o tempo de resposta pode até melhorar... (apenas para constar...)

Mas digo, ao mudar para o MySql, tanto o tempo de resposta no Servidor melhorou (5 a 10 segundos) e também em qualquer outra máquina da rede, teve seu tempo "igualado" ao tempo de resposta do próprio Servidor.

Então o que tenho a dizer... a mudança para o MySql foi a melhor coisa que pude ter feito para meus sistemas.

Quando houver oportunidade, pense com carinho nessa possibilidade !

Abraços !

Eu mudei de dbf para Postgresql via sqlrdd e os meus problemas de lentidão sumiram.
A diferença é muito grande, e não é só nisso, poder usar comandos sql , eliminar boa parte dos índices, não precisar reorganizar e por aí vai.
Agora se não está cogitando sair dos dbf , tem o Letodb que segundo os que usaram, melhorou bastante, principalmente velocidade em rede.

Paulo

Olá Quintas, bom dia.
É bom saber disso, sempre aprendendo.
Dá prá usar HB32 modo console com FireBird tb ?

Mas se fizer o SELECT trazendo tudo que interessa de uma vez, vai usar a capacidade máxima dos baldes, portanto menos baldes e mais rápido.

José Quintas (ou outro usuario clipper). Você me daria umas dicas de como usar a técnica "SELECT" que vc sugeriu acima?
Meus programas são em Clipper 5.01 e ficam mto lentos mesmo na rede.

Grato.

Imagina se o banco SQL tivesse acesso como o DBF tem, via mapeamento de rede, seria o rei da lerdeza.

Banco relacional é rapido pelo conceito, o LetoDB faz basicamente o mesmo que um sql mas usando o DBF.

Lembro em uma ocasião, que atendia um atacadista da minha cidade, usava maquinas antigas e o sistema de clipper que era bem grande funciona bem, algumas operações demoravam 1 minuto em media para processamento, o que era normal pelo volume de dados.

Quando comecei a viajar, não tinha como atender esse cliente mais, e durante um ano verificamos algumas opções de sistema para ele utilizar, então ele trocou o sistema, ai comprou um servidor parrudo da Dell e colocou o oracle rodando, outro conceito, trocou todas as maquinas da rede, a estrutura, comprou equipamentos de primeiro, e um dia veio rindo pro meu lado dizendo que o sistema era mais lento, e eu falei para ele que, se nao epoca que usava o sistema, se tivesse investido em equipamento como fez para rodar o oracle, ele teria mais agilidade.

O banco relacional é excelente, mas tem toda uma estrutura envolvida, e levando em consideração a idade do DBF, ele é rapido, o problema é rodar mapeando unidade, se quiser um ganho excelente, é colocar o sistema em emulação de terminal Linux ou Windows, acaba com 99% dos gargalos.

Vale os amigos olharem com carinho o Postgresql, ele é muito bom, considero melhor que o oracle.

Hoje na empresa que trabalho, mantemos o Postgresql e o Oracle, todos os dados são sincronizados de mais de 400 lojas nos dois bancos, o Postgres tem uma maquina mediana, o oracle tem toda uma estrutura, maquina super mega power, pagam mantenedores para o banco e licença para a oracle, assim como hospedagem dos dados, eu te falo que tudo rodamos no PG, pela versatilidade do SQL dele, o Padrão SQL do oracle é muito injessado, coisas simples de se fazer no Postgres pode ser um parto no Oracle, o Oracle é levemente mais rapido, mas dado a imensa capacidade do servidor que o hospeda, deveria ser ultra-mega-power rapido e não é.

O oracle já saiu do ar e parou muitas vezes ao longo dos ultimos 4 anos, o Postgres segue inteiro e sem nos decepcionar.

É muito facil migrar o DBF e o sistema para uso com Postgres.

vagucs escreveu:...
Banco relacional é rapido pelo conceito, o LetoDB faz basicamente o mesmo que um sql mas usando o DBF.
...

Uma das coisas que quero fazer futuramente é migrar para um banco relacional. Mas, no momento, principalmente pela impossibilidade de me dedicar ao assunto, continuarei usando o velho e bom DBF.

Tempos atrás eu estava lendo sobre os bancos pra entender sobre vantagens e desvantagens entre eles, pra ter uma ideia de qual eu escolheria. Por outro lado, também li alguma coisa sobre o Leto db e chamou minha atenção, mas não cheguei a testar.

Wagner, pelo que você escreveu deduzo que para casos como o meu - o de permanecer usando DBFs-, o Leto db ajudaria muito, está correto? Você o utiliza ou já o utilizou? Qual é a sua avaliação?

Então, nunca utilizei o Leto, mas acredito que sim, vai te ajudar bastante, talvez resolverá seus problemas por um bom tempo.

Duda,

Eu utilizo o Leto e o NetIO e não tenho o que reclamar.
Nunca tive corrupção de dados e indices.
A migração/utilização é tranquila.
Tem vários exemplos aqui no fórum.

Obrigado Wagner e asimoes!

Ainda um pouco fora do assunto deste tópico, mas apenas pra completar, rapidamente: recentemente um cliente que possui uma matriz e 4 pequenas filiais demonstrou interesse em unificar as bases de dados e começar a usar a internet para acessar o sistema, de qualquer um dos 5 locais. O Leto db também pode ser utilizado para esse fim?

Lembrando: ao menos por enquanto, vou continuar usando DBFs.

Sim, pode!

Valeu!

Dê uma lida nisto. https://pctoledo.org/forum/viewto ... 120#p85537

Amigos, sou clippeiro desde a década de 90, (sim, sou vovô), Clipper 5.3b com cdx e as vezes com ntx, faz duas semanas que conheci o Harbour e a HMG 3.3. Cara! Estou muito feliz e conseguindo migrar meu sistema clipper com dbf para Harbour aplicativo de 32 bits usando como base de dados o MySQL.
Depois que você conhece o MySQL você nunca mais vai querer saber de DBF. Vale a pena dedicar bastante para conhecer o MySQL.
Minha aplicação em Harbour em meus testes preliminares pela rede local acessa direto um servidor na locaweb pela internet como se o BD MySQL estivesse no servidor local, não deu pra sentir diferença local/internet.

Um clipper abraço a todos.