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!

#MCTS – #Database #Developer 2008 – Tá chegando

Boa noite, caros leitores!

Em breve estarei postando mais sobre SQL Server, especificamente, mais sobre desenvolvimento. Estou finalizando meus estudos para a prova de segunda-feira para MCTS – Database Developer 2008. Foram dias muito intensos de estudo, porque só tive 16 dias desde o MCITP para estudar.

Creio que, com a ajuda de Deus, estarei conseguindo mais esta vitória na segunda.

Meu objetivo pra esse ano é: todos os MCITP de SQL Server 2008.

Vamos que vamos!

Abraço a todos!

Agora…#MCITP #Database #Administrator 2008!

Boa noite, caros leitores!

Novamente fazia muito tempo que não escrevia em meu blog. Existem muitos assuntos que quero abordar sobre SQL Server em meu blog, mas infelizmente o tempo tem sido muito curto devido aos estudos para as provas!

E o Senhor Jesus me deu mais esta vitória! Consegui no dia 01/07/2011 a certificação MCITP – Microsoft Certified IT Professional Database Administrator 2008. Consegui fazer 815 pontos em 1h10m de prova.

Consegui um livro da própria Microsoft para estudar para essa prova: MICROSOFT SQL SERVER DATABASE DESIGN AND OPTIMIZATION (ISBN: 9780470183748). Não está á venda no Brasil, mas em contato com uma livraria consegui importá-lo. Foi muito importante para meu desempenho na prova. O  livro é bem objetivo, claro e aborda todos os assuntos da Prova que você pouco encontra em outros materiais de SQL Server da própria Microsoft (como NUMA, RAID, etc.)

Essa é uma prova bem mais difícil que o MCTS (óbvio, rsrs). Aborda mais assuntos do dia-a-dia de um DBA e suas necessidades. Muitas vezes, sendo necessário escolher a “resposta mais correta”.

É isso pessoal, queria compartilhar com vocês essa vitória e também agradecer primeiramente a Deus que me dá condições todos os dias para seguir em frente, à minha esposa que me motiva, me ajuda, tem paciência comigo…e a todos meus amigos que oraram e intercederam por mim! Principalmente aos Jovens do Ministério Geração Santa da Comunidade Cristã Zona Sul que estiveram orando e torcendo ao meu lado!

Dedico essa vitória a Deus e à minha amada esposa, Karol! Que inclusive meu deu mais uma certificação MDK – Marido da Karol! Rsrs

Até mais pessoal! Até o próximo post!

#Problemas para #pesquisar textos que possam conter #acentos errados? #Collations do #SQLServer resolverão seu problema

Fazia um bom tempo que não postava, porque estou me preparando para a prova 70-450 ( MCITP SQL Server 2008 – Implementation & Maintenance).

Mas hoje me sobrou algum tempo e decidi postar algo muito útil; porém, ainda pouco utilizado (pelo menos pelos locais onde tenho passado): Collations.

COLLATION

Definindo de uma forma bem básica, é um conjunto de regras sobre um determinado conjunto de caracteres baseado principalmente em idiomas. Para você entender melhor pense na língua portuguesa e suas regras e agora imagine regras na escrita alemã ,ou na japonesa, ou ainda na árabe. São totalmente diferentes e precisam ser tratadas diferentes no armazenamento e na busca. Para que isso seja possível existem os Collations.

Mas não posso ser tão simplista e deixar de comentar que as Collations também podem controlar detalhes da forma de pesquisar, como: sensibilidade à maiúsculas ou não, sensibilidade à acentos ou não, etc).

Para entender melhor como escolher um collation para a coluna do seu banco de dados, vamos analisar como é a nomeclatura dos Collations. Por exemplo, um dos Collations mais utilizados no Brasil: SQL_Latin1_General_CP1_CI_AI.

Para maior didática, vou dividir o nome da Collation da seguinte forma:

SQL_Latin1_General_ -> É o nome

CP1_ ->Significa que vai usar Unicode para codificação e ordenamento (não vou falar muito, pois não será o foco hoje)

CI_ -> Case Insensitive, ou seja, não sensível a maiúsculas e minúsculas. Se aqui tivesse CS, então seria Case Sensitive, ou seja, sensível a maiúsculas e minúsculas

AI_ ->Accent Insensitive, ou seja, não sensível à acentos. Se aqui tivesse AS, então seria Accent Sensitive, ou seja, sensível a acentos

E ainda existem outras partes da nomeclatura, mas para as língua latinas não vão importar; portanto, não vou me alongar nesse assunto.

 

Para examinar outras collations você pode executar a seguinte consulta que vai retornar o nome da Collation e a descrição:

select * from fn_helpcollations()

NA PRÁTICA

Para ficar mais fácil o entendimento sobre Collations vou usar uma solução de um problema recente na empresa em que trabalho.

Os usuários estavam cadastrando nomes de pessoas e colocavam acento no nome e outros não, gerando duplicidade e inconsistência no banco de dados. Por exemplo, um usuário cadastrava “João da Silva” e outro cadastrava “Joao da Silva”. Estamos falando da mesma pessoa; porém dois registros foram inseridos porque a Collation utilizada era a SQL_Latin1_General_CP1_CI_AS, que é sensível à acentos, sendo assim, considera os dois nomes diferentes.

A solução foi alterar a Collation do campo em questão para usar a SQL_Latin1_General_CP1_CI_AI (que não é sensível ao acento). Usei a seguinte query:

ALTER TABLE [dbo].[tb_cliente]
ALTER COLUMN [nm_cliente] varchar(50) collate SQL_Latin1_General_CP1_CI_AI not null

Pronto, agora ninguém mais conseguirá cadastrar “Joao da Silva” e depois “João da Silva”, pois isso ocasionará um erro devido a esse campo ser Unique. E ao consultar, tanto faz escrever “Joao” como “João”, o SQL Server retornará o usuário em questão.

CUIDADOS

Só lembrando dos cuidados que se deve ter ao modificar um collate:

  • verificar se o campo participa de algum índice (clustered ou nonclustered)
  • verificar se a modificação não vai gerar conflito de chave primária ou estrangeira e nestes casos, verificar qual o registro correto e qual pode ser excluído

 

Por hoje é só, caros leitores…

Hoje é sexta e é dia de curtir a esposa e uma boa comida.

Até o próximo post!

Fredy Esmeraldo

Implementation & Maintenance