Aprendendo a usar CURSOR – SQL Server

Boa noite!

Depois de um tempo se escrever é bom voltar a publicar algo um pouco mais substancial, hehehe…

Não gosto do consumo de processamento que eles geram, mas são muito úteis e bastante poderosos na manipulação de dados. Nesse primeiro momento não vou me aprofundar em CURSORES, mas apresentá-lo aqueles que estão iniciando no Microsoft SQL Server.

O que é CURSOR?

De maneira direta e simplista é uma espécie de ponteiro que nos ajuda a manipular e exibir dados consultados.

Como funciona?

Para entender é interessante um método de dividir como um cursor é declarado e o que ele faz. Segue abaixo:

1. Declara CURSOR (DECLARE)

2. Abre o CURSOR (OPEN)

3. Alimenta variáveis com os dados do CURSOR (FETCH)

4. Fecha e desaloca o CURSOR (CLOSE e DEALLOCATE)

<‘o’> Simples assim? Simples assim.

Vamos para um exemplo prático. Vou utilizar uma tabela cliente cujo o código de criação segue abaixo:

–Código de criação da tabela CLIENTE e alguns INSERTS só para exemplificar o CURSOR

create table CLIENTE
(
CodigoCliente int null,
NomeCliente varchar(50) null
)
go

insert into CLIENTE values (1,’Cliente 1′)
insert into CLIENTE values (2,’Cliente 2′)
insert into CLIENTE values (3,’Cliente 3′)
insert into CLIENTE values (4,’Cliente 4′)
insert into CLIENTE values (5,’Cliente 5′)

Agora vou utilizar o cursor fazer uma manipulação “inútil” para exibir os dados. É somente didática. Não serve de muita coisa, pois sem CURSOR seria imensamente fácil fazê-la. Vou utilizar nos comentários os passos que indiquei a vocês anteriormente para que fique mais fácil a compreensão:

–1. Declara CURSOR (DECLARE)
declare c_aprendendoCursor cursor for
select
CodigoCliente,
NomeCliente
from
CLIENTE

–2. Abre o CURSOR (OPEN)
open c_aprendendoCursor

–3. Alimenta variáveis com os dados do CURSOR (FETCH)
declare @cod int
declare @nome varchar(50)

fetch next from c_aprendendoCursor into @cod, @nome

print ‘Código do Cliente: ‘ + cast(@cod as varchar)
print ‘Nome do Cliente: ‘ + @nome
print ‘————————————————————————————‘

fetch next from c_aprendendoCursor into @cod, @nome

print ‘Código do Cliente: ‘ + cast(@cod as varchar)
print ‘Nome do Cliente: ‘ + @nome
print ‘————————————————————————————‘

fetch next from c_aprendendoCursor into @cod, @nome

print ‘Código do Cliente: ‘ + cast(@cod as varchar)
print ‘Nome do Cliente: ‘ + @nome
print ‘————————————————————————————‘

fetch next from c_aprendendoCursor into @cod, @nome

print ‘Código do Cliente: ‘ + cast(@cod as varchar)
print ‘Nome do Cliente: ‘ + @nome
print ‘————————————————————————————‘

–4. Fecha e desaloca o CURSOR (CLOSE e DEALLOCATE)
close c_aprendendoCursor
deallocate c_aprendendoCursor

Lembrando para quem já usa CURSOR que esse é um exemplo bem simplista! Por isso não vou me deter explicando maiores detalhes do CURSOR e nem sobre WHILE e @@FETCH_STATUS, etc, etc, etc…

Serão cenas do próximo capítulo! Rs

Espero que tenha sido útil. Até a próxima!

Resposta Desafio SQL Server – Cadê o meu join?

Boa noite!

Quanto tempo não escrevo? Rs… Vamos tentar manter regularidade, né?

Bom, antes de responder o Desafio, quero deixar todos os créditos para o incrível Fabrício Catae e seu blog http://blogs.msdn.com/b/fcatae/archive/2012/01/23/desafio-cad-234-meu-join.aspx

O desafio foi criado por ele e não tenho nenhum crédito sobre isso. Só achei interessante repassar, pois a resposta dele é um excelente exemplo do funcionamento do optimizer do SQL Server.

O Optimizer do SQL é inteligente para saber que RegiaoID não pode ser NULL, então quando é feita uma consulta que foge uma FK ou uma check constraint (no exemplo em questão: “WHERE regiaoId IS NULL”) o optimizer nem precisa acessar a tabela para ter certeza que não vai retornar nenhuma linha.

Até a próxima!

MVA – Microsoft Virtual Academy

Olá! Boa tarde!
Quer estudar para as provas de certificação Microsoft?! A própria Microsoft oferece alguns cursos gratuitos! É rápido e fácil de acessar!

Os materiais são bem introdutórios, mas já é uma ajuda, né?!

Quer acessar o MVA? Clique Aqui

Abraço!

Introdução ao SQL Server 2012 – Livro Grátis

Olá! Bom dia!

Depois de um milênio sem postar nada estou de volta! Rsrs

E com uma excelente notícia: a Microsoft cada vez mais estimula seus usuários a se aperfeiçoarem em suas ferramentas!

A prova disso é a liberação de um livro gratuito sobre introdução ao SQL Server 2012! Isso mesmo: gratuito! “De grátis”! Lógico, que de graça só o PDF! Rsrs Se interessar o livro, ele custa aproximadamente U$ 15,00.

Se quiser ler a matéria completa: http://blogs.msdn.com/b/microsoft_press/archive/2012/03/15/free-ebook-introducing-microsoft-sql-server-2012.aspx

Se quiser baixar somente o livro: Clique Aqui

Até a próxima pessoal!

UNION x UNION ALL

Muitas vezes vejo pessoas com dúvida sobre a diferença entre UNION e UNION ALL, apesar de ser simples a diferença.

Explicando de uma forma um pouco “grosseira”:

  • UNION realiza um DISTINCT entre os SELECTS, ou seja, os registros que tiverem informação repetida só apareceram uma vez no ResultSet
  • UNION ALL simplesmente une os SELECTS, ou seja, os registros que tiverem informação repetido apareceram no ResultSet quantas vezes eles existirem

Existem algumas regras para se usar o UNION e o UNION ALL (e são as mesmas):

  • Os ResultSet devem conter o mesmo número de colunas e devem ser do mesmo tipo (INT, NUMERIC, VARCHAR); caso contrário o SQL Server retornará um erro;
  • O nome das colunas deverá estar no primeiro SELECT e será atribuído as demais colunas;
  • A cláusula de ordenação ORDER BY só poderá ser usada após o último SELECT e ordenará todo o resultado que foi unido pelo UNION ou pelo UNION ALL; caso contrário, o SQL Server retornará um erro.

Dica de Perfomance: Se você precisa unir resultados que não podem se repetir e você conhece os resultados do SELECT e já sabem que eles não se repetem, então você deve usar o UNION ALL, pois ele não utilizará o DISTINCT entre os SELECTS o que causa um ganho de PERFOMANCE. Já se você usar o UNION o SQL Server utilizará um DISTINCT em cima de um resultado que não se repete, ou seja, consumirá recursos À toa.

Vamos ao exemplo prático:

–Declara variáveis de tabela para exemplo

DECLARE @tabela1 as TABLE(codigo int null, nome varchar(50) null)

DECLARE @tabela2 as TABLE(codigo int null, nome varchar(50) null)

 

–Insere dados na @tabela1

INSERT INTO @tabela1 VALUES

(1,‘nome1’),

(2,‘nome2’),

(3,‘nome3’),

(4,‘nome4’)

 

–Insere dados na @tabela2

INSERT INTO @tabela2 VALUES

(1,’nome1′),

(3,’nome3′),

(5,’nome5′),

(7,’nome7′)

 

–Exibe os campos da @tabela1

SELECT

                *

FROM

                @tabela1

–Exibe os campos da @tabela2    

SELECT

                *

FROM

                @tabela2

 

–Note que somente os registros do nome1 e nome3 se repetem nas tabelas

 

–Agora veja o resultado da união das duas consultas utilizando o UNION

–Os campos que possuem registros repetidos nas duas tabelas são exibidos apenas uma única vez

SELECT

                *

FROM

                @tabela1

UNION

SELECT

                *

FROM

                @tabela2

 

 

–Agora veja o resulta da união das duas consultas utilizando o UNION ALL

–Os campos que possuem registros repetidos nas duas tabelas são exibidos quantas vezes existirem nas consultas envolvidas

SELECT

                *

FROM

                @tabela1

UNION ALL

SELECT

                *

FROM

                @tabela2

 

 

 Analisando os planos de execução você pode ver porque o melhor é usar o UNION ALL no caso de você ter certeza de que os campos não vão se repetir, pois, neste caso, a consulta custa 22% a menos no UNION ALL por causa do DISTINCT (que equivale a 63% dos 35% gastos) do custo total  que é utilizado no UNION. Veja abaixo: 

Plano de Execução com UNION

 

 

Plano de Execução com UNION ALL

 

 Bom…por hoje é só. Espero que vocês tenham conseguido entender a diferença entre UNION e UNION ALL. Mais do que isso, que vocês tenham aprendido quando usar cada um deles!

Até o próximo post!

MCTS – Database Development 2008

Consegui pessoal!

Hoje foi mais um dia de vitória! O Senhor me concedeu mais essa vitória!

Com muito esforço e estudo consegui o MCTS Database Development.

Agradeço a Deus por tudo,  à minha esposa por toda a paciência e apoio e à todos que oraram e torceram por mim!

Agora só faltam mais 3 para conseguir toda a trilha MCITP de certificações SQL Server 2008. Depois dessas só o sonhado MCM (Microsoft Certified Master).

Estou só esperando mais um livro chegar dos EUA para iniciar os estudos para o MCITP Database Development 2008.

Durante esses dias vou estar postando algumas novidades do desenvolvimento em SQL Server 2008 bem interessantes.

Abraço! E até o próximo post!

Mudanças #Prometric – #Reagendamento de provas

Caros leitores,

A prometric mudou algumas regras para agendamento de provas Microsoft.

Agora são 15 dias de antecedência para reagendar suas provas. Portanto, recomendo muita cautela ao marcar suas provas e se organizar para prever 15 dias antes se você estará pronto pra fazer o teste.

Qualquer outra novidade manterei-os informados!

Abraço!