Introdução ao SQL Server – Aula 2.2

Nesta segunda aula veremos como trabalhar com tipos de dados para armazenar Texto e Data.

Data/Hora

Armazenar data no banco de dados requer saber o intervalo de data/hora que se pretende armazenar e também a precisão desejada.

Os tipos DataTime, DataTime2 e SmallDataTime permitem armazenar datas e horas com intervalos específicos.

Datetime (8 bytes) de 1753-01-01 a 9999-12-31
Datetime2 (6-8 bytes) de 0001-01-01 a 9999-12-31
SmallDateTime (4 bytes) de 1900-01-01 a 2079-06-06

Já o tipo DateTimeOffset, permite armazenar datas e horas e também o UTC (fuso horário) da localidade em questão, permitindo cálculos precisos para sistemas que trabalham com mais de um fuso horário.

DateTimeOffset (8-10 bytes) 0001-01-01 a 9999-12-31

Para situações que se deseja somente armazenar data ou somente hora, existem os tipos Date e Time, reduzindo em alguns bytes o tamanho dos dados a serem armazenados.

Date (1-3 bytes) de 0001-01-01 a 9999-12-31
Time (3-5 bytes) de 00:00:00.0000000 a 23:59:59.9999999

Introdução ao SQL Server – Aula 2.1

Nesta segunda aula veremos como trabalhar com tipos de dados para armazenar Texto e Data.

Texto

Armazenar texto no banco de dados pode não ser uma tarefa fácil se não se sabe o tamanho dos textos que deseja armazenar e se não se sabe se o texto terá tamanho variável ou não.

O tipo de dados CHAR, permite armazenar textos com tamanho fixo, exemplo siglas como as de UF (AC, PR, SP, RJ…) e IATA (CWB, GRU, GIG…), de forma a utilizar 1 byte por caractere, podendo ter tamanho fixo para até 8000 caracteres.

Sintaxe: CHAR(n. de caracteres)

O tipo de dados VARCHAR, permite armazenar textos com tamanho variável, exemplo nomes e logradouros, de forma a utilizar 1 byte por caractere e 2 bytes para identificar o “final” do texto, podendo armazenar textos com mais de 8000 caracteres.

Sintaxe: VARCHAR(n. de caracteres), acima de 8000: VARCHAR(MAX)

Também há tipos de dados específicos para armazenar caracteres de outros idiomas, como árabe, hebraico, chinês e coreano, tendo um prefixo N, como NCHAR e NVARCHAR, utilizando 2 bytes para cada caractere, tendo assim tamanho fixo limitado à 4000 caracteres.

Sintaxe: NCHAR(n. de caracteres)

Sintaxe: NVARCHAR(n. de caracteres), acima de 4000: NVARCHAR(MAX)

Introdução ao SQL Server – Aula 1.2

Depois de definido quais as colunas que a tabela terá, se faz necessário definir os tipos de dados que serão utilizados para cada coluna, ex.:

1. Nome do cliente, precisar ser armazenado como “Texto”,
2. Número da rua como “Numérico”,
3. Preço da gasolina como “Numérico”,
4. Data de validade como “Data”…

Para isso, no SQL Server tem tipos de dados para cada uma destas situações:

1. Inteiro (-1, 0, 1, 2, 3, 4, …),
2. Decimal (149.99),
3. Flutuantes (π, 0.12515481…),
4. Monetário ($ 149.99),
5. Data/Hora (01/12/1987),
6. Booleano (Verdadeiro/Falso),
7. Texto

Obs.: Também existem outros tipos com finalidades bem específicas e complexas, como os tipos binários, XML, hierárquicos e geométricos, que não requerem atenção no momento.

Inteiros

Para o primeiro tipo numérico do SQL Server, se tem os tipos inteiros (bigint, int, smallint, tinyint), que possuem capacidade de armazenar números sem casas decimais, de diferentes intervalos.

O tinyint é capaz de armazenar números inteiros de 0 a 255, utilizando um 1 byte. Sendo suficientemente capaz de salvar o DDD de um telefone ou a idade de uma pessoa.

O smallint é capaz de armazenar números inteiros de -32,768 a 32,767, utilizando um 2 byte. Sendo suficientemente capaz de salvar a temperatura em ºC de uma cidade.

O int é capaz de armazenar números inteiros de -2,147,483,648 a 2,147,483,647, utilizando um 4 byte. Sendo suficientemente capaz de salvar um CEP sem os “-”.

O bigint é capaz de armazenar números inteiros de -9,223,372,036,854,775,808 a 9,223,372,036,854,775,807, utilizando um 8 byte. Sendo suficientemente capaz de salvar um CNPJ ou CPF.

Decimais

Para o segundo tipo numérico do SQL Server, se tem os tipos decimais (Decimal ou Numeric), que permitem armazenar números com casas decimais precisas, ou seja, o preço de uma casa 190.000,00, tem 8 dígitos, sendo 2 dígitos após a virgula, que será representado pelo tipo Decimal(8,2), segundo a sintaxe: Decimal(quantidade de dígitos, quantidade de dígitos após a virgula)

Esta precisão requer a utilização de um número um pouco maior de bytes em comparação aos outros tipos numéricos, conforme a relação:

1 a 9 dígitos, 5 bytes.
10-19 dígitos, 9 bytes.
20 a 28 dígitos, 13 bytes.
29 a 38 dígitos, 17 bytes.

Flutuantes

Para o terceiro tipo numérico do SQL Server, os tipos flutuantes (real e float) não requerem da mesma precisão dos tipos decimais, por consequência utilizam menos bytes (de 4 a 8 bytes), e podem armazenar números maiores que os decimais e inteiros, como dízimas periódicas e o valor de π, mas devido a sua falta de precisão, não são adequados para dados monetários.

Monetários

O quarto tipo numérico, existe especificamente para armazenar dados monetários utilizando menos bytes do que os tipos numéricos, conforme abaixo:

Money, para armazenar -922,337,203,685,477.5808 a 922,337,203,685,477.5807 em 8 bytes
SmallMoney, para armazenar – 214,748.3648 a 214,748.3647 em 4 bytes

Booleano

Um “quinto tipo numérico”, existe especificamente para armazenar dados do tipo 1:verdadeiro/0:falso denominado “bit“ , utilizando 1 byte para cada 8 colunas deste tipo, ou seja, 1 coluna bit ocupa 1 byte na tabela, assim como 8 colunas bit ocupam também ocupam 1 byte, e 9 a 16 colunas ocupam 2 bytes, assim por diante.

Introdução ao SQL Server – Aula 1.1

Olá pessoas, faz um bom tempo que não escrevo nada no blog, mas achei interessante disponibilizar alguns assuntos que estou trabalhando em um treinamento de SQL realizado na EuroIT, sendo o primeiro deles um passo-a-passo sobre como criar/normalizar tabelas no SQL Server, que achei interessante compartilhar no blog, devido à abordagem mais prática adotada.

Para criar uma tabela em qualquer banco de dados, é necessário pensar como organizar os registros que serão inseridos nela, para não termos situações onde temos um monte de dados sem uma ordem adequada ou que permita identificar o que esta salvo lá, ex.:

João Batista Queiroz, Travessa da Lapa 5034, Joãozinho, 83792-000, 39382872A, 56877848454-54, 012.216.549-12, M, I, 2006-12-12, 1985-01-01

Para isso requer o uso de colunas para organizar estes dados, ex.:

Nome	Endereço	Apelido	…
João Batista Queiroz	Travessa da Lapa 5034	Joãozinho	…

Também é importante utilizar nomes que realmente especifiquem que dado esta armazenado em cada coluna e nas tabelas, ex.: Coluna Nome da tabela Cliente, para armazenar o nome do cliente.

Obs. 1: Em algumas empresas também se adotam nomenclaturas para as tabelas e as colunas, ex.: T0001_CLIENTE, C0001_NOME, N0001_DDD, N0001_TELEFONE …

Ao criar as colunas, se deve pensar também no trabalho que será necessário para organizar estes dados nestas colunas, como no caso os “endereços”.:

1. Que se pode não ser dividido, tendo toda a informação em uma coluna “endereço”

2. Que se pode dividir nas colunas: logradouro, número, bairro, complemento, CEP, cidade, estado, país…

3. Que se pode dividir em uma forma mais detalhada: tipo de logradouro (rua, avenida, praça…), prefixo do logradouro (coronel, marechal, tenente, presidente, são, santa, santo, novo…), logradouro (Teixeira Martins, José, Maria), sufixo do logradouro (I, II, III…)…

O problema do detalhamento para deixar os dados bem organizados, é o trabalho que será necessário para organizar estes dados em muitos colunas ao ponto de ficar muito complexo e requerer um esforço demasiado em comparação à forma que estes dados serão utilizados pelos usuário.

Obs. 2: Também se frisar a existência de limites de colunas para as tabelas, como 1024 colunas no SQL Server (ref. http://msdn.microsoft.com/en-US/library/ms143432.aspx)

E vamos para mais um exemplo de Deadlock…

Artigos relacionados:
Exemplo de Deadlock no SQL Server
Monitorando Deadlocks do SQL Server com SMO

Fonte:
https://www.facebook.com/1mpics

Oportunidades – SQL Server, JAVA, .NET, Testes – Stefanini Curitiba

Olá pessoas, atendendo um pedido da Miriam B. de Oliveira da Stefanini, segue algumas oportunidades para desenvolvedores, DBA e analista de testes.

Desenvolvedor .NET (2 vagas neste momento e outras vão abrir no início do ano):

•Desenvolvedor C# com sólida experiência na análise e desenvolvimento utilizando as tecnologias C#, ASP.NET
•Experiência com Web Services e com Ajax
•Conhecimentos em bancos de dados SQL Server
•Necessário inglês fluente (eliminatório)

Enviar seu CV com pretensão salarial para mioliveira@stefanini.com – Assunto: Desenvolvedor .Net C# – Curitiba

Desenvolvedor JAVA (1 vaga neste momento e outras vão abrir no início do ano:

•Java EE 6;
•JPA (Java Persistence API) / Eclipse Link;
•JSF 2.0;
•EJB as the programming model / Web Services;
•Experiência mínima de 2 anos em programação;
•Inglês fluente (requisito eliminatório).

Enviar seu CV com pretensão salarial para mioliveira@stefanini.com – Assunto: Java – Curitiba com inglês fluente

DBA SQL Server (1 vaga neste momento, com possibilidade de abrir mais uma vaga no primeiro semestre de 2013):

•Experiência em desenvolvimento/suporte (3anos), conhecimentos em TSQL, modelagem de bancos de dados relacionais, padronização de código.
•Experiência em configuração/administração de bancos de dados SQL Server, tunning, análise de segurança de bancos de dados, gerenciamento de ambientes de alta disponibilidade, dimensionamento de hardware, suporte a desenvolvedores.
•Certificação Microsoft SQL Server MCTS ou MCITP.
•Conhecimentos sobre arquitetura de aplicações WEB, experiência em administração de servidores Windows, conhecimentos VMware, Reporting Services e Sharepoint.
•Inglês fluente.

Enviar seu CV com pretensão salarial para mioliveira@stefanini.com – Assunto: BDA SQL Server – Curitiba com inglês fluente

Analista de testes (1 vaga no momento com possibilidade de abertura de outra vaga no primeiro semestre de 2013):

•Boa habilidade analítica + conhecimento em metodologias de desenvolvimento;
•Entendimento de falhas de software comuns + experiência de pelo menos 1 ano em System Test + experiência em vários esforços de teste (desejável) ;
•Conhecimento do sistema ou aplicativo em teste (muito desejável);
•Habilidade para geração e manutenção de documentação de sistemas
•Inglês fluente.

Enviar seu CV com pretensão salarial para mioliveira@stefanini.com – Assunto: Analista de testes – Curitiba

UNPIVOT ou Reverse PIVOT no Excel 2010 – Transformando colunas em linhas

Bom dia pessoas,

Como um autentico viciado em SQL Server, tenho problemas com o Excel para fazer coisas que normalmente são bem “simples” no T-SQL, sendo a principal delas o UNPIVOT, para transformar colunas em linhas.

Como penso que eu não sou o único que sofre com isso, elaborei um tutorial simples (totalmente workaround), conforme abaixo.

Primeiramente, temos a massa de dados com vários itens com valores em colunas por ano:

Utilizando o atalho “ALT + D + P”, entramos no tradicional PivotTable Wizard, informando a opção “Multiple consolidation ranges”:

Prossigo para a tela seguinte:

Selecionamos o “Range” da massa de dados, ou seja, a tabela inteira:

Criamos uma nova aba para a PivotTable:

Nesta nova aba, teremos a PivotTable:

Com o botão direito sobre o último campo da PivotTable, clicamos em “Show Details”:

E teremos os dados no formato esperado:

Agora só formatar:

Verificar a versão dos dados de uma tabela por CHECKSUM

Olá pessoas!

Recentemente, encontrei um script bem interessante para realizar o CHECKSUM de todos os dados de todas as colunas de uma tabela, fiz algumas alterações mínimas para reduzir o código do script original, e ficou desta forma:

DECLARE @schema_name sysname
SET @schema_name = 'dbo'

DECLARE @table_name sysname
SET @table_name = 'Nome da tabela'

DECLARE @column_list VARCHAR(MAX)

SELECT @column_list =
	COALESCE(@column_list + ', ', '') + QUOTENAME(COLUMN_NAME)
FROM INFORMATION_SCHEMA.COLUMNS
WHERE TABLE_NAME = @table_name
AND TABLE_SCHEMA = @schema_name

DECLARE @sql VARCHAR(MAX)
SET @sql = 'SELECT CHECKSUM_AGG(CHECKSUM({@column_list})) FROM [{@schema_name}].[{@table_name}]'

SET @sql = REPLACE(@sql, '{@column_list}', @column_list)
SET @sql = REPLACE(@sql, '{@schema_name}', @schema_name)
SET @sql = REPLACE(@sql, '{@table_name}', @table_name)

EXEC (@sql)

Esta consulta retorna o CHECKSUM de todos os dados da tabela de forma rápida (na maioria das vezes), e permite verificar por meio deste CHECKSUM se a tabela foi ou não alterada, sendo uma ótima alternativa comparar alterações em tabelas similares em bancos distintos e criar uma estrutura simples de versionamento.

A única limitação que encontrei para este script é a necessidade de um tratamento diferenciado para colunas XML:

Msg 8116, Level 16, State 4, Line 1
Argument data type xml is invalid for argument X of checksum function.

Referências

Script original:
http://stackoverflow.com/questions/1560306/calculate-hash-or-checksum-for-a-table-in-sql-server

Função CHECKSUM:
http://msdn.microsoft.com/en-us/library/ms189788.aspx

Função CHECKSUM_AGG:
http://msdn.microsoft.com/en-us/library/ms188920.aspx

Artigos relacionados:

Comparando a estrutura de tabelas diferentes
http://sqlfromhell.wordpress.com/2010/01/09/query-from-hell-comparando-a-estrutura-de-tabelas-diferentes/

Red Gate – Overview – SQL Data Compare
http://sqlfromhell.wordpress.com/2011/05/23/red-gate-overview-sql-data-compare/

Visual Studio 2010 – Data Compare
http://sqlfromhell.wordpress.com/2011/01/27/visual-studio-2010-data-compare/

Três anos de blog | Pausa para o mestrado

Então pessoas, três anos de blog e agora o blog ficará um pouco órfão, pois nesta oportunidade do Mestrado, eu estarei deixando de lado minha carreira técnica na área de TI, para atuar como acadêmico na área da Administração.

Neste momento que tenho que me dedicar às varias atividades do mestrado (aulas, leituras, artigos, seminários, reuniões, pesquisas…) e manter o mesmo desempenho no trabalho, não estarei escrevendo mais no blog, ou pelo menos não na mesma regularidade, mas continuarei respondendo as dúvidas que vocês têm enviado nos comentários ou por e-mail.

Aniversário de 3 anos do SQL From Hell!!

Há três anos iniciou o SQL From Hell, sem muita perspectiva do que iria se tornar, e hoje, me surpreendo que um blog escrito em português sobre assuntos técnicos bem específicos, tenha conseguido ajudar tantas pessoas, além das várias críticas e elogios que tem recebidos.

Procurei nestes três anos tratar assuntos que eu gosto, como SMO, SQL CLR, Service Broker, FOR XML e XQuery, também artigos que escrevi com o objetivo de disponibilizar tutoriais para ajudar no dia-a-dia dos novos DBAs, como habilitar SQL Authentication, habilitar conexão remota, alterar as portas de conexão do SQL Server, usuários orfãos, scripts para validar CNPJ, entender JOINs, scripts de cidades, scripts para o dicionários de dados e vários outros assuntos, que algumas vezes não estavam diretamente ligados com SQL Server, como os tutoriais de NoSQL e alguns artigos sobre gestão e carreira.

Obrigado todos aqueles que contribuíram com esta iniciativa!!!