[firebase-br] otimizador de consultas do firebird

[Eduardo Jedliczka]

Maglan,

O exemplo do livro é válido! Já estudei isto na pós, mas eram dicas para
criar um DataWareHouse, (recomendando várias coisas para ganhar performanse
exclusivamente em Select - já que por questões de estabilidade, o DWH e a
base de produção devem ficar separadas)

Mas ainda há outra coisa. Cada banco de dados possui uma realidade
diferente.

Na pós, sempre conversamos sobre Oracle, MS-SQL, FireBird e PostGreeSQL, e
das vantagens e desvantagens de cada um.

No caso do exemplo que você mostrou, no Oracle 9, eles terão absolutamente a
mesma performance, pois o banco "reescreve" o seu select para que tenha uma
melhor performance.

Esta regra, portando não vale para o Oracle, mas faz uma diferença
substancial no MS-SQL.

[s]

=====================
Eduardo Jedliczka
GeraSoft Informática
Apucarana - PR
=====================

----- 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
>