Comando SQL x XBASE

[sygecom]

O simples fato de nao ter uma relação de chave primaria e estrangeira no DBF já é um grande motivo para migrar para SQL com tudo bem amtrado.

[Karine Lima Almeida]

sygecom, me desculpe, mas não entendi, o que vc sugere?

[alxsts]

Olá!

Seja bem-vinda ao fórum Karine!

Como devem saber, em um SGBD a performance está intimamente ligada ao modelo de dados. Como estão os índices das tabelas usadas nesta consulta, se é que existem? Procure criar índices nas tabelas para as colunas envolvidas na cláusula WHERE.

[Karine Lima Almeida]

Olá alxsts, eu tenho indices na tabela sim, são esses:

[alxsts]

Olá!

Pode postar o comando SQL?

[Karine Lima Almeida]

USE tab AS "select * from MEDIATOR.GRUPOS t where exists ( select recno from MEDIATOR.DBTMARK where recno = t.recno )" PERMANENT

[JoséQuintas]

Se entendi direito, o comando vai fazer 1 milhão de pesquisas.

Apenas tentativas:

SELECT * FROM GRUPOS WHERE recno IN ( SELECT RECNO FROM DBTMARK )

Pelo menos ao invés de pesquisar cada código, carregaria uma lista. (dependendo do tamanho da segunda tabela)


SELECT * FROM GRUPOS LEFT JOIN DBTMARK ON GRUPOS.RECNO = DBTMARK.RECNO

De qualquer jeito, no mínimo o servidor vai percorrer 1 milhão de registros, e depende da estrutura.
Por exemplo, tabelas com TEXT com muito conteúdo, é demorado.

E dependendo do tamanho do resultado, vai precisar muita memória no servidor.

Difícil imaginar aonde usaria esse resultado, caso seja 1 milhão de registros.

Aliás... se quer saber os códigos que existem em dbtmark, não seria mais prático...

SELECT DISTINTIC RECNO FROM DBTMARK

[alxsts]

Olá!

Experimente este:

Código: Selecionar todos

USE tab AS "SELECT * FROM MEDIATOR.GRUPOS t JOIN (SELECT recno FROM MEDIATOR.DBTMARK) t1 ON t.recno = t1.recno)" PERMANENT

É recomendável não usar

Código: Selecionar todos

SELECT * FROM ...

Prefira nomear as colunas:

Código: Selecionar todos

SELECT col1, col2 ... coln FROM tabela...

Obs:
- não testei o SQL acima. Pode haver erros...
- não conheço Mediator.
- se persistir a lentidão, faça um teste com ADO em um programa separado, para medir a performance e comparar.

[JoséQuintas]

Complementando:
Se a intenção é pegar os dados da primeira tabela, com código cadastrado na segunda, pode ser interessante inverter, caso a segunda tabela seja menor.

SELECT [lista de campos] FROM DBMARK INNER JOIN GRUPOS ON DBMARK.RECNO = GRUPOS.RECNO

Desta forma já tem os códigos que interessam, e só pesquisa os dados na primeira tabela.

Supondo que a primeira tabela tenha um milhão de registros, e a segunda tenha apenas um, vai substituir um milhão de pesquisas por apenas uma.

[Karine Lima Almeida]

Olá pessoal, obrigada pelas dicas, vou fazer os testes!

[janio]

Karine,

Um outro teste que vc pode fazer qndo notar alguma lentidão eh fazer a consulta no seu banco pelo HeidSql e ver qnto tempo levou... e depois fazer a mesma consulta pelo mediator e verificar se houve diferença no tempo de processamento.

Dessa forma da pra ter uma ideia de onde está o problema!

[paiva_dbdc]

BOm dia.

testei varias vezes com Mysql, Fire e Postgres e realmente ta difícil mudar do DBF.

Mais rápido, MUITO mais simples etc etc.

uso tudo em TS.

MAIS a minha duvida é sobre uma informação que tive.

me falaram que mesmo em DB existe problema de Índices e que o IDEAL seria não usar índices.
mais se não houver índices as Pesquisas seriam + lentas então seria tipo uma sinuca de bico (rs)

ou este problema de índice é devido ao PRODUTO que a pessoa esta usando e que relatou este fato ?

PAiva

[Karine Lima Almeida]

janio,

então é assim,
USE qry AS "SELECT * FROM MEDIATOR.GRUPOS WHERE SITUACAO='1' order by CIDADE " // SEM O SCROLLABLE APENAS 1,5 SEGUNDOS

//45,623 total registros
-----------------------------------------------------
USE qry AS "SELECT * FROM MEDIATOR.GRUPOS WHERE SITUACAO='1' order by CIDADE " SCROLLABLE // com SCROLLABLE cerca de 19 segundos.

//45,623 total registros

eu não tenho duvidas de que é o SCROLLABLE que torna o resultado mais lento, porém se eu não usa-lo, INDEXKEY() não é definido, o skip -1 não funciona, entre outras funções que deixam de funcionar.

[Itamar M. Lins Jr.]

Bom se, é assim, vai cair naquela mesma coisa que eu já falei aqui... Lógica do DBF nos SGBD´s da vida, é um problema a longo prazo.
Seria bom ver isso com SQLMIX, já que não usa nada disso que o pessoal do Mediator usa.
As poucas consultas que fiz usando SQLMIX foram praticamente instantâneas.

É o caso das outras coisas que essas lógicas tem que fazer, DELETED, RECNO, RLOCK, ETC... tudo isso tem que ser verificado, criado, atualizado... ai fica mais lento.

Saudações,
Itamar M. Lins Jr.

[alxsts]

Olá!

Qual seria a necessidade do DbSkip(-1)? Teu sistema roda em Windows ou Linux/Unix?