Rumo a certificação 70–761

Terceiro encontro — Gerenciando dados com Transact-SQL

Lindos e lindas, bom dia… boa tarde… boa noite!!!

Vamos para a segunda parte o primeiro capítulo do livro da Microsoft Press, e vamos continuar conversando sobre as consultas.
O fato importante é que 90% das nossas interações com o banco de dados acontecem através de queries com a estrutura básica SELECT xxx FROM xxx, ou seja, vamos dar um salto quando este capitulo acabar .

Lembram que no nosso encontro número 0 nós instalamos o SQL Server? (https://medium.com/tempestade-de-dados/sql-server-2016-89c323e36791) Instalamos mas ainda não temos dados para testar e testar as nossas consultas. Por isso hoje achei importante para os nossos estudos mostrar para vocês como restaurar um banco para ser o nosso sandbox (lugar que podemos testar, testar, e testar…)

Vamos aos passos:
1- Acessem o link https://github.com/Microsoft/sql-server-samples/releases/tag/wide-world-importers-v1.0
2- Baixe o arquivo WideWorldImporters-Full.bak
3- Abram o SQL Server Management Studio
4- Clique com o botão direito em Bancos de Dados, e escolham a opção Restaurar Banco de Dados

5- Em Origem selecione a opção Dispositivo, e clique no botão destacado para buscar o arquivo WideWorldImporters-Full.bak

6- Clique no botão Adicionar (em destaque) e selecione o arquivo WideWorldImporters-Full.bak

7- Clique em OK

8- Verifique as informações, se quiser renomeie o BD… Experimentem, sejam curiosos… Se tudo der errado, restaure o banco de dados novamente!

Vejam por exemplo o botão Script, lembram que eu disse que é preciso conhecer os comandos, mas não precisamos nos martirizar se não decoramos cada parâmetro ? Este tipo de funcionalidade é o motivo.

9- Clique no botão Ok.
10- Verifique o banco de dados no Pesquisador de Objetos (Object Explorer, juro que vou tomar vergonha e instalar a versão em inglês!)

FROM

• Lembrando do último encontro… FROM é a primeira clausula avaliada logicamente;
  • É onde você indica as tabelas que farão parte da query;
  • Nesta clausula são aplicados os joins;
  • As tabelas podem ter seu nome representado por duas partes, por exemplo, a tabela HR.Employees, onde:
   o HR é o nome do schema
  SCHEMAs são coleções de objetos dentro do SQL Server. A vantagem de usar um schema é a possibilidade de criar grupos e usuários de forma mais fácil, por exemplo, posso colocar todas as tabelas de RH no schema RH e dar permissão de leitura neste schema só aso funcionários do RH. A outra vantagem é a possibilidade de agrupar fisicamente os objetos que fazem parte de um schema para administração de backups.
   o Employees é o nome da tabela
  • O schema não é obrigatório… Mas eu aconselho a usar sempre;
  • Você pode usar um alias (lembrando que um alias é um apelido) para as tabelas. O Alias pode ser atribuído de duas formas diferentes:
  o <nome da tabela> <Alias>
  o <nome da tabela> AS <Alias>
  • Embora as duas formas estejam corretas eu sou fã da segunda!
  • Usem nomes menores no alias, facilita a escrita da query.
  o Comentário da Dani eu ainda opto por usar nomes mais significativos
  • Com o alias você altera o nome da tabela durante a sua execução, então nada de fazer a salada mista de usar o alias só quando quer, se criou um alias ele será usado na query, se vc tentar usar o nome da tabela, vai dar erro.

SELECT

• A clausula mais poderosa de todas! (Opinião da Dani)
• Tem dois papéis principais
o É onde definimos o retorno da nossa query. Nela são avaliadas as expressões que definem as colunas da query resultante, atribuindo a eles um alias se for necessário;
o Usar a clausula DISTINCT para eliminar os registros duplicados do retorno da query
• Quando queremos que a query retorne todas as colunas de uma tabela, podemos usar o “*” , ao invés de explicitamente declarar os nomes das colunas. NÃO É UMA BOA PRÁTICA FAZER ISSO.
• Assim como na clausula FROM podemos definir alias para as expressões que fazem parte do retorno da query. A forma de declarar o alias é igual e eu prefiro usar a forma mais completa. Quanto mais fácil de ler a query, menos complicadas são as manutenções (Opinião da Dani, de novo).
o <expressão> <Alias>
o <expressão> AS <Alias>
• Atenção com as virgulas no select! Se vc esquecer de colocar uma virgula entre o nome de duas colunas, o SQL Server vai interpretar que a segunda coluna é um ALIAS. Entende o perigo?

• Um uso importante do alias é nomear expressões, porque sem o alias elas resultam em uma coluna sem nome

• Uma diferença importante entre o T-SQL e o SQL padrão, é que no padrão não existe SELECT sem FROM, e no T-SQL existe

• Podemos delimitar o nome das colunas com “” ou com []. Quando o nome segue o padrão definido delimitar o nome da coluna é opcional, mas se uma das regras abaixo não for respeitada é necessário delimitar o nome:
  o O primeiro caracter deve ser ser uma letra definida no padrão Unicode 3.2, ou o “_”, ou “@” ou “#”. Os caracteres seguintes podem ser letras, números “$”
  o Não podem ter espaços e nem palavras reservadas para o T-SQL

Filtrar dados com predicados

• Vamos começar lembrando que NULL não é um valor (embora eu mesma sempre que não me policio cometo a gafe de falar valor nulo…Desculpem mas é um hábito ruim que eu não perco)
• Se vcs tentarem fazer uma query e na clausula WHERE colocarem a seguinte condição <nome da coluna> = NULL a sua consulta nunca retornará nenhum resultado., pelo simples fato de NULL não ser um valor é impossível para o SQL Server fazer esta comparação. Mas se quisermos retornar na query as colunas que são nulas devemos usar o seguinte predicado: <nome da coluna> IS NULL

Se quisermos filtrar o retorno da nossa query, com as colunas que não são nulas podemos usar o predicado <nome da coluna> IS NOT NULL

Combinando Predicados

• No mundo real, as nossas consultas podem ter vários predicados… que são várias condições. Ou seja o retorno de nossa consulta serão as linhas que obedecerem um conjunto de condições. Combinamos as condições com os operadores lógicos AND, OR e NOT
• Use o NOT para inverter uma condição, por exemplo…
o SELECT NomeFuncionario FROM Funcionario WHERE NOT(situação = ‘ativo’)
o Traduzindo o comando, selecione o nome do funcionário, da tabela de funcionários onde a situação não seja igual a ‘ativo’
• Cuidado com a precedência na hora de montar suas condições…
o NOT precede o AND, que precede o OR
• Assim como na matemática use parênteses para que as condições sejam executadas na ordem correta
• Predicados são avaliados da esquerda para a direita, logicamente. Quando falamos da execução física o plano de otimização é quem decide qual condição será avaliada primeiro

Filtrando caracteres

• Antes de falar sobre este tipo de filtro é legal falar de conversões implícitas… Isso ocorre quando comparamos dados de tipos diferentes, mas que são compatíveis ou que comparamos o resultado de uma expressão. Internamente o SQL converte os dados para depois fazer a consulta. Por exemplo… Existe o tipo de dados NVARCHAR (strings do tipo UNICODE com tamanho variável) e existe o tipo de dados VARCHAR. Quando usamos comparações com o NVARCHAR sempre colocamos um N antes da string por exemplo:
  WHERE lastname = N’Monteiro’
  Isso indica para o SQL Server que a palavra ‘Monteiro’ é um texto UNICODE e a query será executada da melhor maneira. Entretanto se escrevermos a query da seguinte maneira:
  WHERE lastname = ’Monteiro’
  E a coluna lastname é do tipo NVARCHAR, internamente o SQL Server converterá a string ‘Monteiro’ para UNICODE para depois verificar a condição. Entendem que as conversões utilizam recursos desnecessariamente?
  • Temos o predicado LIKE para consultar padrões de string, devemos usa-lo na clausula WHERE e ele tem o seguinte padrão: <coluna> LIKE <padrão>
  o Vejam o link https://docs.microsoft.com/en-us/sql/t-sql/language-elements/like-transact-sql com a documentação das possibilidades de uso do LIKE

Filtrando datas e horas

• Cuidado com o filtro de datas!!! Porque o formato usado depende do idioma da linguagem associado ao login. Normalmente os DBAs mais ajuizados usam o padrão americano (opinião da Dani…) existe também a propriedade DATEFORMAT que o DBA atribui para o login (só para causar mais confusão, é possível criar um loogin com idioma padrão americano e o formato de data japonês)
• E como sair desta sinuca de bico? Uma solução é usar um formato neutro como “20170813” que sempre será entendido pelo SQL Server como ano, mês e dia, independentemente do idioma.
o O formato “2017–08–13” é considerado neutro para os tipos DATE, DATETIME2 e DATETIMEOFFSET, mas não é considerado neutro para os tipo DATETIME E SMALLDATETIME, sendo assim tenha cuidado!
• Podemos usar a função CONVERT para converter as datas para um determinado padrão
o A função CONVERT é muito útil, não só para converter datas deem uma olhada na documentação
o Existe também a função CAST que tem o mesmo objetivo, mas é padrão ANSI
https://msdn.microsoft.com/pt-br/library/ms187928(v=sql.120).aspx
• Quando usamos filtros com colunas do tipo DATETIME é necessário tomar cuidado com a precisão e com os arredondamentos, use intervalos fechados e na mesma precisão dos dados

Vamos parar neste ponto… Estamos quase finalizando o primeiro capítulo e temos nosso banco de dados para os testes!
Agradeço pela companhia na jornada!
Dani