[firebase-br] otimizador de consultas do firebird

[Maglan Cristiano Diemer]

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
>