PC Toledo

DBF ou SQL acesso via rede (qual e o mais rapido) ??

tenho arquivo imenso de 1 giga em BDF e tenho CDX no
PC e rapido via SEEK na rede demora mais
(pode ate ser placar de rede limite de 100 ) em bora existam placas rede 1 giga
utilizo seven

estou pensando em coloca para SQL (gostaria saber se mais rapido o acesso)
ou nao tem diferença nenhuma na questao do """acesso""

? :{

Em SQL vc faz uma consulta (query) e o retorno desta query q irá trafegar na sua rede, exemplo se vc quer pesquisar os clientes de determinada cidade seria algo mais ou menos assim:

select * from clientes where cidade = "TAL"

Suponhamos q o retorno desta consulta seja 5 clientes, serão estes dados q irão trafegar na rede resumidamente falando.

Agora com relação a DBF/CDX eu não tenho certeza, mas acredito q ele traz toda tabela trafegando na rede, agora se for isto mesmo teria q ver se tem como fazer trafegar somente os dados q são requeridos, tipo o retorno da query em SQL.

Agora uma solução paliativa q pode ser tentada é trabalhar com Terminal Service ai todo o processamento é feito no Server e fica super rápido, não sei se o colega já tentou isto, mas poderia estar vendo caso queira faça uma pesquisa aki mesmo no fórum por Terminal Service q encontrara muitas referências.

[]´s

Olá Fladimir,

Apenas para registro: Mesmo em DBF (CDX, NTX ou outro), apenas os dados filtrados é que trafegam na rede.

Outrossim, por literatura (nunca usei SQL), tenho lido que SQL tem maior velocidade no tráfego em rede, até porque ele foi projetado com esse intuito: oferecer maior performance em conexão de rede.

Jairo Maia escreveu:Apenas para registro: Mesmo em DBF (CDX, NTX ou outro), apenas os dados filtrados é que trafegam na rede.

Creio que você está equivocado. O Clipper é uma ferramenta essencialmente de acesso local. Logo, qualquer manipulação de DBFs e/ou índices (seja do tipo que for) é totalmente feito na máquina em que a aplicação está rodando. Não é possível ter apenas os dados filtrados trafegando pela rede. E note: não importa onde os arquivos estão hospedados, pois o processamento dos dados só pode ser feito num único local: na aplicação que precisa do resultado desse processamento. Portanto, é essencial que a aplicação tenha acesso a todos os dados do arquivo.

Aliás, a (obsoleta) tecnologia de acesso local é famosa pelo alto consumo de banda de rede. Por isso sempre se desaconselha o uso de recursos como SET FILTER, por exemplo. O indicado é sempre tentar fazer as consultas pelos índices. Esses arquivos também têm de trafegar pela rede, mas sendo menores, o tempo gasto na pesquisa é menor.

Mas não há como comparar Clipper/DBF/índices com SQL, justamente porque SQL não é uma ferramenta, mas sim uma linguagem que, primordialmente, é utilizada em sistemas gerenciadores de bancos de dados (SGBD), como Firebird, MySQL, etc. Esses gerenciadores sim, processam no servidor os dados conforme a consulta é feita pela aplicação, e fazem trafegar pela rede apenas os dados resultantes desse processamento. Isso diminui o tráfego e aumenta a velocidade. Aliás por SQL ser uma linguagem, ela até pode ser utilizada para fazer consultas a bases DBF. É só uma questão de interface.

Pelo exposto, dá pra ter uma idéia da vantagem que é migrar dos DBFs para SGBDs. Além da imensa gama de recursos adicionais, a velocidade de trabalho é imensamente maior. A título de ilustração, fiz uma busca no Firebird numa base de CEPs. De propósito pedi o nome do logradouro pelo CEP de uma rua de SP-capital. Foi só o tempo de clicar na busca e o resultado apareceu. Calculo que o Firebird passou por uns 400.000 registros antes de encontrar o alvo. Aliás, separei as bases por UF. Então o Firebird teve de varrer outros 25 Estados (ordem alfabética) até chegar no alvo. Isso diminuiu bastante a velocidade.

O Fladimir lembrou algo interessante: o uso de "thin clients" para rodar o Clipper, como o que se consegue pelo Terminal Service, é uma alternativa que realmente faz diminuir o tráfego de dados pela rede. Está longe do ideal, claro. Mas certamente melhora a situação da velocidade.