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.

Anúncios

3 pensamentos sobre “Introdução ao SQL Server – Aula 1.2

  1. Acredito que valores que tenho zero em seu inicio (cep, cnpj, cpf, etc), se armazenados em campos do tipo INT, causem problemas, já q nesse tipo de campo o zero no inicio é cortado. Concorda ?

    • Bob, os campos CEP, CNPJ e CPF têm uma largura fixa, de forma que a aplicação pode entender facilmente que para exibir um CPF número ‘7822265512’ se aplicará a máscara ###.###.###-##, ou seja, 078.222.655-12.

      O único campo que vejo como problemático como você relatou é o telefone, que não tem largura fixa e pode começar com 0, mas se em um cenário com telefones de 8 ou 10 dígitos é passível de utilizar a máscara ####-#### ou (##) ####-####, e você até pode criar um campo tinyint ou bit para especificar a máscara a ser utilizada.

      Utilizar um BIGINT (8 bytes) no lugar de CHAR(11) para CPF significará uma economia de 3 bytes, INT(4 bytes) no lugar de CHAR(8) para CEP economia de 4 bytes, e pode significar uma economia ainda maior para CNPJ, e principalmente para os bancos de dados que salvam até os pontos e traços do CEP, CPF e CNPJ, que são muito comuns por ai.

      Em um cenário crítico que trabalhei, a mudança de alguns campos do tipo texto para inteiros, somado ao uso adequado dos tipos inteiros, data/hora, decimais, monetários e textos já significou uma economia de superior a 40% do tamanho dos bancos de dados, poupando custos com discos e armazenamento dos backups, além de uma substancial melhora na performance.

Deixe um comentário

Preencha os seus dados abaixo ou clique em um ícone para log in:

Logotipo do WordPress.com

Você está comentando utilizando sua conta WordPress.com. Sair / Alterar )

Imagem do Twitter

Você está comentando utilizando sua conta Twitter. Sair / Alterar )

Foto do Facebook

Você está comentando utilizando sua conta Facebook. Sair / Alterar )

Foto do Google+

Você está comentando utilizando sua conta Google+. Sair / Alterar )

Conectando a %s