[firebase-br] otimizador de consultas do firebird

[Nilton Souza]

Olá Maglan,

Acredito que quando ele esteja falando de criar uma terceira tabela, esta
seria uma tabela temporária. Alguns SGDB's são capazes de criar tabelas
temporárias baseadas em resultados de uma pesquisa como por exemplo o MySQL,
Informix ou o próprio MSSQL. Tais tabelas são controladas pelo SGDB então
caso você esqueça de DROPAR as mesmas o próprio servidor fará isso quando
sua conexão for encerrada.

Infelizmente o nosso querido Firebird não possui tal recurso, mas se não me
falha a memória isso já está no RoadMap da versão 2

Em alguns SGDBs isso é extremamente necessário, como é o caso do Informix 7
onde eu tenho consultas que quando efetuadas sem o auxílio de uma tabela
temporária demoram uma eternidade para serem processadas (mas é uma
eternidade mesmo !!!), porém quando utilizada uma tabela temporária o
resultado é instantâneo.

Resumindo, nem todas as regras de otimização são úteis em todos os SGDBs do
mercado, acho que vc deve se preocupar apenas com as "Formas de
Normalização" e criar seus selects da forma mais clara e objetiva possível,
sem fazer muitas voltas.... Na maioria das vezes a melhor solução também é a
mais simples...

[]'s
Nilton Souza

----- Original Message -----
From: "Maglan Cristiano Diemer" <maglan em univates.br>
To: "FireBase" <lista em firebase.com.br>
Sent: Thursday, November 18, 2004 10:25 PM
Subject: Re: [firebase-br] otimizador de consultas do firebird


Pessoal,

Obrigado pelas contribuições. Realmente também
acredito que usar o join (explícito) facilita
o otimizador do SGBD e clareza do código.

Mas, a minha pergunta foi mais genérica.
O exemplo que veio a memória foi Pessoas
com Cidades. Mas esse não é um exemplo prático.

Vejo o trecho de texto que estou me referindo
do livro SQL Performance Tuning de Peter Gulutzan,
Trudy Pelzer, pela Addison Wesley, 2002.

O que voces tem a dizer sobre isso?

" *** Avoid the Join Strategies ***

You can sometimes avoid a join by transforming an SQL statement to a
simpler equivalent. For example, here is an SQL statement that could
benefit from constant propagation:


SELECT * FROM Table1, Table2

    WHERE Table1.column1 = Table2.column1

      AND Table1.column1 = 55


When the equals operator is in the restrictive clause and the same
column is in both the joining clause and the restrictive clause, such a
statement boils down to a non-join, like this:


SELECT * FROM Table1, Table2

    WHERE Table1.column1 = 55

      AND Table2.column1 = 55

GAIN: 5/8 if both columns indexed


There isn't a transform for every case though. The most difficult and
most effective joining strategy is to do the joining in advance and
store one piece of information; namely, which rows in Table1 would
relate to rows in Table2 if there was an equijoin. There are several
ways to blaze a trail that the DBMS can follow in such cases. We'll
mention two: join indexes and composite tables."

Mais adiante neste capítulo, os autores falam de uma
técnica de composição. De duas tabelas, criar uma
terceira com todos os campos das duas tabelas.
E, as consultas, serem realizadas na terceira tabela,
a qual seria uma composição das duas primeiras.

E dai eu pergunto? Qual é o custo disso? Será
que vale a pena? Se, pela modelagem eu faço duas
tabelas, porque iria fazer uma tabela composta
com todos os campos das duas tabelas ? Tenho que
manter a tabela composta atualizada... e isso
gera custo e espaço.
Será que vale a pena? Se sim, então eu manteria
somente a tabela composta.

Para exempleficar, a ideia do autor resultaria
nso seguintes selects (que seriam equivalentes)

1)
SELECT * FROM Table1, Table2

    WHERE Table1.column1 = Table2.column3

2)
SELECT * FROM Composite

    WHERE column1 = column3

GAIN: 8/8

Sei que esse assunto é chamado de
denormalização. Mas, pergunto novamente
será que vale a pena ?

Maglan

Maglan Cristiano Diemer wrote:
> Pessoal,
>
> Suponha duas tabelas relacionadas.
>
> create table PESSOAS {
>   codigopessoa integer not null, (chave primaria)
>   nome varchar(100),
>   codigocidade integer (chave estrangeira)
> }
>
> create table CIDADES {
>   codigocidade integer not null, (chave primaria)
>   nome varchar(100)
> }
>
>
> Eu quero saber se o Interbase interpreta
> os seguintes selects da mesma forma
>
> 1)
> select *
> from pessoas, cidades
> where pessoas.codigocidade = cidades.codigocidade
> and cidades.codigocidade = 10
>
> 2)
> select *
> from pessoas, cidades
> where pessoas.codigocidade = 10
> and cidades.codigocidade = 10
>
>
> Esse é um exemplo pequeno. Mas voces entenderam, né?
> Li no livro sobre otimizacoes em bancos SQL, que o
> segundo select (apesar de trazer o mesmo resultado
> do primeiro) é bem mais rapido do que o primeiro.
>
> Penso que o otimizador do banco poderia cuidar disso, não ?
>
> Ou voces ainda poderiam mostrar outra alternativa que
> seja mais rapida ainda ?
>
> O que voces tem a dizer sobre isso ?
>
> Maglan
>
>
> ______________________________________________
> FireBase-BR (www.firebase.com.br) - Hospedado em www.bavs.com.br
> Para editar sua configuração na lista, use o endereço
> http://mail.firebase.com.br/mailman/listinfo/lista_firebase.com.br
>



______________________________________________
FireBase-BR (www.firebase.com.br) - Hospedado em www.bavs.com.br
Para editar sua configuração na lista, use o endereço
http://mail.firebase.com.br/mailman/listinfo/lista_firebase.com.br