Pessoal, conforme prometi deixo aqui o link para o PPT e os arquivos que utilizei na palestra.

Foi um prazer participar desta jornada que contou com a presença de vários profissionais do Mercado.

No dia 17 eu dividi a bancada com o Rodrigo que é mestre em Engenharia de Construção Civil pela Politécnica da Universidade de São Paulo, que deu um show falando sobre Projetos, citando o seu caso de sucesso em realidade virtual.

Quando a professora Lidia me chamou para iniciar a palestra, fiquei bem contente com o que ví, vários alunos bem interessados em participar e aprender sobre SQL Server, pena que o tempo foi curto, mas com certeza valeu a pena.

Espero que tenham gostado, eu gostei…

Agradeço a professora Simone que me encontrou pela Internet e ao Google(ou será que ela usou Bing?) por me apresentar a Ela…

Segue algumas fotos e o link para download dos arquivos…

Exibir Álbum Completo

Abraço.

É por isso que eu sempre digo, apesar do inglês sofrível de ouvir, nossos amigos indianos são demais :-)

Acesse o link abaixo para visualizar vários cursos relacionados a IT e afins …

http://nptel.iitm.ac.in/index.php

Deixo como destaque o curso de Database Design, e mais destaque ainda para os módulos sobre Query Processing and Optimization :-).

Database Design

14 - Query Processing and Optimization [56:41]
15 - Query Processing and Optimization II [56:55]
16 - Query Processing and Optimization - III [57:19]

Divirta-se!

Pessoal convido a todos que estiverem aqui pelo interior de São Paulo, para participar da jornada de Sistema de Informação que acontecerá na FAEF em Garça.

Tive a honra de receber o convite para participar como Palestrante, no dia 17/11 próxima terça-feira vou falar sobre Certificações e SQL Server.

Se estiver por aqui... conto com sua presença...

Valew

Pessoal,

Depois que eu postei falando sobre o comportamento do QO em relação a Foreign Keys, resolvi enviar um exemplo para o meu Mestre em Query Processor Conor Cunningham.

Bom como sempre ele deu um show de resposta... Concordo com ele que deve ser MUITO difícil decidir o que entra e o que fica de fora do QO, encontrar este balanceamento perfeito entre o tempo de criação do plano versus a quantidade de analises que são efetuadas é sem dúvida uma árdua tarefa.

Eu sonho com o dia em que conseguiremos de alguma forma deixar o QO tão esperto a ponto de não se preocupar com as “Mentes Brilhantes” que vemos por ai... Até que este dia não chegue, escreva suas consultas com atenção e quando terminar de escrevê-la sempre pense, ficou bom?

Leitura imperdível.

http://blogs.msdn.com/conor_cunningham_msft/

Abraço.

Pessoal, depois da WebCast que fiz falando sobre o Query Optimizer, quero compartilhar um caso onde na minha opinião ele infelizmente não foi tão esperto assim :-(

Por sinal o vídeo já esta disponível para download.... é só acessar o link de cadastro para a webcast e baixar...

Veja bem, no meu banco de dados tenho 2 tabelas assim...

CONCC030 – Tabela de propostas, e CONCC036 tabela que relaciona uma proposta com uma Cota.

As chaves das duas tabelas são, ID_Empresa, ID_Documento, ID_Tipo_Documento. Na tabela CONCC036 eu tenho uma foreign key forçando a integridade entre as tabelas. A foreign key é formada pelas 3 colunas que acabei de mencionar.

Tenho uma consulta assim:

SELECT ID_Bem
  FROM CONCC030
INNER JOIN CONCC036
    ON CONCC036.ID_Tipo_Documento = CONCC030.ID_Tipo_Documento
   AND CONCC036.ID_Documento = CONCC030.ID_Documento
WHERE CONCC036.ID_Empresa = 1
   AND CONCC036.ID_Cota = 123456

Bom, como podemos observar, o join não esta sendo feito pelas 3 colunas da foreign key... esta faltando especificar a coluna ID_Empresa, porém ela esta no WHERE, fazendo um filtro por ID_Empresa = 1.

O que podemos concluir com isso, ora, o QO sabe que existe uma foreign key entre as tabelas e sabe quais são as colunas da FK, porque então não utilizar o filtro da tabela CONCC036.ID_Empresa = 1 (WHERE) e também aplicar este filtro na CONCC030.ID_Empresa ?

Com certeza o desenvolvedor que escreveu esta consulta não especificou o ID_Empresa no join justamente porque ele sabia que a coluna seria utilizada no where. Mas isso causou um problema para o QO, pois ele não conseguiu utilizar um índice que temos para fazer o link entre as duas tabelas, já que o índice esta ordenado justamente pela ordem, ID_Empresa, ID_Documento, ID_Tipo_Documento....

O QO poderia muito bem aplicar o filtro em CONCC030.ID_Empresa = 1 e utilizar as outras colunas no join para fazer o filtro...

Outra coisa triste, a funcionalidade que mencionei na WebCast sobre ele descartar as tabelas caso a existência de uma foreign key, só funciona para foreign Keys ligadas por apenas uma coluna... ou seja, se você tiver uma foreign key que liga uma tabela por mais de uma coluna e tentar utilizar a funcionalidade que mencionei, não vai conseguir...

Bom, fica a seguinte dica, ao escrever uma consulta, SEMPRE(does not matter what!) especifique todas as colunas no seu join...

Abraço...