Professional Documents
Culture Documents
Nesse exemplo, estamos solicitando dados das tabelas products e categories onde o a coluna
unitprice da tabela products maior que 10. Porm, se voc notar na figura abaixo, ver que o
produto est sendo repetido 1 vez para cada categoria. Isso acontece porque no informamos na
instruo SQL, a correspondncia de uma tabela com a outra, por isso est acontecendo o produto
cartesiano.
Para corrigir esse problema, iremos informar no mesmo SELECT, mais uma condio na clusula
WHERE, criando assim uma correspondncia entre as tabelas.
SELECT products.productid, products.productname, products.categoryid, categories.categoryid,
categories.categoryname
FROM products, categories
WHERE products.categoryid = categories.categoryid
AND products.unitprice > 10
Dessa forma, os dados retornaro sem repetio e com as correspondncias de cada tabela.
Bom, esse foi o primeiro artigo em que estaremos explicando e mostrando a linguagem SQL e suas
vertentes.
Dvidas?? Mande um e-mail para leolopes@blogdati.com.br
INSERT
O comando utilizado para inserir dados em uma tabela dentro do banco de dados, o INSERT. A
sintaxe do INSERT consistem em:
INSERT INTO Nome_da_Tabela (coluna1, coluna2, coluna3, , colunaN)
VALUES (valor1, valor2, valor3, , valorN)
ou
INSERT INTO Nome_da_TabelaInserir (coluna1, coluna2, coluna3, , colunaN)
SELECT coluna1, coluna2, coluna3, , colunaN FROM Nome_Tabela_Origem
Como mostrado na sintaxe, tanto podemos realizar um insert com uma nica linha, como tambm
podemos realizar o insert atravs de um select, com dados de outras tabelas.
Exemplos:
Temos uma tabela chamada Shippers:
Como podemos ver essa tabela contm 3 colunas, ShipperID, CompanyName e Phone. Atualmente
temos 3 registros e vamos inserir um novo registro nessa tabela:
INSERT INTO Shippers (CompanyName, Phone)
VALUES (Minha Transportadora, (11) 2121-3232)
Mas pera Lo! Na tabela Shippers, voc mostrou que ela tem 3 colunas. Por que no comando
insert, voc somente indicou 2 colunas e a coluna ShipperID foi preenchida?? Bom, na maioria dos
bancos de dados, quando voc est criando sua tabela, poder indicar, quando for do tipo
numrica, que a coluna seja auto-incrementada. Esse o nosso caso, a coluna ShipperID tem o
atributo auto-incremento habilitado, por isso gera uma numerao automtica.
Vamos agora inserir novos registros na tabela Shippers, mas agora com dados que so de outra
tabela:
INSERT INTO Shippers (CompanyName, Phone)
SELECT CompanyName, Phone FROM customers WHERE city = Sao Paulo
UPDATE
UPDATE o comando que iremos utilizar quando queremos alterar algum dado j existente em
nossas tabelas. A sintaxe do UPDATE consiste em:
UPDATE Nome_Tabela_Atualizar
SET coluna1 = valor1, coluna2 = valor2, colunaN = valorN
WHERE condicao
IMPORTANTE: A clusula WHERE opcional, ela responsvel por indicar quais linhas na tabela
sero atualizadas. A omisso dessa clusula na sua instruo, far com que todas as linhas da
tabela sejam atualizadas.
Exemplo:
Vamos atualizar o registro da transportadora Queen Cozinha da tabela Shippers
DELETE
O comando DELETE utilizado para apagar linhas em uma tabela. A sintaxe do comando DELETE
consistem em:
DELETE FROM Nome_tabela
WHERE condicao
IMPORTANTE: A clusula WHERE opcional. Ela responsvel por indicar quais as linhas da tabela
sero deletadas. A omisso dessa clusula na sua instruo, far com que todas as linhas da tabela
sejam apagadas.
Exemplo:
Vamos apagar o registro da transportadora Speedy Express
preferir os relacionamentos que essa tabela ter com outras tabelas pai
< constraint> : So regras agregadas a colunas ou tabelas. Assim podemos definir regras para o
preenchimento dessa coluna, como se obrigatrio ou no o preenchimento, se existe um valor
padro, ou at uma checagem de valor, por exemplo, se a coluna s dever aceitar M ou F
(Masculino ou feminino)
Exemplo:
Vamos criar duas tabelas, uma de pacientes e outra de convenios. A tabela de convenios, ter os
campos: nome do convenio. A tabela de pacientes, contendo os dados: nome, endereco, data de
nascimento, sexo e convenio. Para criar esses dois objetos, segue a instruo:
CREATE TABLE tb_Convenio
(
id_Convenio INTEGER,
nm_Convenio VARCHAR(50) NOT NULL
PRIMARY KEY (id_Convenio)
)
No comando acima, criamos a tabela tb_Convenio, com os campos id_Convenio, nm_Convenio e
definimos que o campo id_Convenio ser nosso campo chave primria nessa tabela. Tambm
definimos com a opao NOT NULL que a coluna nm_Convenio, sempre dever ser preenchida
CREATE TABLE tb_Paciente
(
id_Paciente INTEGER,
nm_Paciente VARCHAR(60) NOT NULL,
dt_Nascimento DATETIME NOT NULL,
des_Endereco VARCHAR(100) NOT NULL,
Sexo CHAR(1) CHECK (UPPER(Sexo) = M OR UPPER(Sexo) = F),
fk_Convenio INTEGER
PRIMARY KEY (id_Paciente),
FOREIGN KEY (fk_Convenio) REFERENCES tb_Convenio (id_Convenio)
)
Nesse comando criamos a tabela de pacientes com o nome tb_Paciente. Observe que colocamos
uma coluna chamada fk_Convenio. Criamos essa coluna , para indicar o convenio correspondente a
esse paciente. Note que criamos uma referncia para a tabela tb_Convenio, com isso s
conseguiremos inserir registros que tenham referncia na tabela tb_Convenio. Tambm criamos
uma regra para a coluna Sexo, assim s poderemos inserir os valores M ou F nessa coluna
Alterar tabela ALTER TABLE
Com esse comando, iremos alterar as definies na estrutura da nossa tabela, seja incluindo ou
alterando ou excluindo colunas. Inserindo regras ou excluindo-as. Segue a sintaxe desse comando:
11
formatar os discos que iro armazenar Dados, Log e Temp utilizando Cluster Size no tamanho de
64K. Nas unidades do SO e SWAP, pode-se utilizar a formao padro com Cluster Size de 4K.
MEMRIA
Quanto mais memria melhor, porm existem algumas parametrizaes necessrias, tanto no SO
quanto no SQL Server para melhor utilizao da memria. Em servidores com Windows Server
2003:
At 2Gb de memria, no so necessrias parametrizaes especiais.
Utilizando at 4Gb de memria, temos que utilizar a opo /3G no arquivo Boot.ini do SO e
habilitar a opo AWE no SQL Server.
Acima de 4Gb de memria, temos que utilizar a opo /PAE no arquivo Boot.ini do SO e habilitar a
opo AWE no SQL Server.
OBS: Vale lembrar que para melhor utilizao de memrias, acima de 4GB recomendo a utilizao
da plataforma 64 bits.
OBS2: Lembre-se sempre de reservar memria para o SO, pois o SQL Server fominha e ir alocar
toda a memria disponvel. sempre bom reservar pelo menos 1Gb de memria para o SO.
Segue um exemplo de um arquivo Boot.ini no qual a opo /PAE foi adicionada
[boot loader]
timeout=30
default=multi(0)disk(0)rdisk(0)partition(2)\WINDOWS
[operating systems]
multi(0)disk(0)rdisk(0)partition(2)\WINDOWS=Windows Server 2003, Enterprise /fastdetect /PAE
Agora um exemplo de como habilitar o AWE no SQL Server
sp_configure show advanced options, 1
RECONFIGURE
GO
sp_configure awe enabled, 1
RECONFIGURE
GO
Bom pessoal, essas foram algumas prticas recomendadas para instalao do SQL Server. muito
importante conhecer o ambiente e a aplicao que ir utilizar seu banco de dados, para decidir qual
a melhor configurao.
Dvidas, sugestes, reclamaes, elogios, fique a vontade para enviar um e-mail.
leolopes@blogdati.com.br
ndices Parte 1
13
Ol pessoal!!
Nesse artigo irei falar sobre ndices. Sempre que construmos um banco de dados, no podemos
pensar somente em como armazenar os dados, mas tambm na velocidade em que retornaremos
esses dados nas operaes.
Imaginem uma consulta em um banco de dados de clientes de uma instituio bancria, nessas
tabelas provavelmente teremos milhes de registros. Agora imagine voc consultar somente 1
cliente no meio desses milhes de registros. Se no tiver uma organizao, o tempo de resposta
para essa consulta ser muito alto, para isso criamos ndices. Os ndices funcionam como catlogos
organizados, de forma a ajudar na localizao dos registros dentro das tabelas. Funciona
basicamente igual aos ndices dos livros, como apontadores dos lugares onde esto as informaes
que queremos encontrar.
Em banco de dados, os ndices so criados nas colunas das tabelas. Funcionaro como ponteiros ou
atalhos para a localizao fsica dos registros. Quando criamos um ndice, o SGBD (Sistema
Gerenciador de Banco de Dados), automaticamente criar um novo objeto, onde sero organizados
e armazenados fisicamente os apontadores para os registros da(s) coluna(s) da tabela que criamos
o ndice.
Ento, para deixar o banco de dados com um tempo de resposta satisfatrio, s criar ndices em
todas as colunas?
A resposta NO. Como diria um amigo meu, isso uma faca de dois legumes.
Como acabei de mencionar, os ndices so gravados fisicamente no disco, portanto a cada registro
que for catalogado no ndice, este ser gravado na estrutura de dados e tambm na estrutura do
ndice. Agora imaginem termos uma tabela com 200 colunas e um ndice para cada coluna,
totalizando 200 ndices. Quando realizar um insert nessa tabela, havero, no mnimo 201 operaes
de gravao (1 para os dados e outras 200 para os ndices). O que pensar ento se tivermos que
inserir 1 milho de registros nessa tabela. Esse o principal motivo para no criarmos ndices para
todas as colunas de uma tabela.
Mas em qual coluna devemos criar um ndice ento?
Por padro, quando criamos um banco de dados seguindo as boas prticas das formas normais,
criaremos relacionamentos entre as tabelas. Sendo assim, a 1FN (Primeira forma normal), nos diz
que devemos identificar uma chave primria na tabela. Quando criamos a chave primria ou
primary key (PK) de uma tabela, essa criada automaticamente como ndice, pois ela organiza os
dados fisicamente. Ainda na 1FN, temos a recomendao de criarmos outras tabelas, para no
termos dados repetidos dentro de uma tabela, e para a coluna que tivermos esse relacionamento,
na tabela primria ela ser uma PK e na tabela secundria, ela ser uma FK (foreign key), nesse
caso, tambm devemos criar um ndice nas colunas FKs.
Outro ponto importante de se ressaltar ao escolher uma coluna para criar ndices, a sua
seletividade. Quanto maior a sua seletividade, ou seja, quanto mais valores diferentes a coluna
tiver, melhor. No criaremos, por exemplo, um ndice numa coluna que s contm 2 tipos de
valores, como Sexo (M ou F). Outro fator, observar as colunas que so mais usadas para filtrar os
dados daquela tabela, como por exemplo, colunas com datas, pois no adianta voc criar um ndice
em uma coluna que no frequentemente utilizada para filtrar os dados.
Bom pessoal, falamos aqui de uma forma bem genrica sobre os ndices. Nos prximos artigos, irei
explicar e demonstrar, como funcionam os ndices na particularidade dos principais bancos de
dados de mercado de hoje em dia.
At a prxima!
ndices Parte 2
Ol pessoal, dando continuidade aos artigos sobre ndices, agora abordaremos os ndices no SQL
Server.
Para acessar os dados dentro das tabelas, o SQL Server utiliza dois modos, o Table Scan e os
ndices.
No Table Scan, o SQL Server realiza uma varredura fsica, linha a linha, at encontrar os dados
solicitados. Ento se o SQL Server tiver que realizar uma varredura numa tabela inteira, linha a
linha, isso significa que ruim? Sim e no.
Devemos ao mximo evitar os table scans em um banco de dados SQL Server. Se partirmos do
princpio que nosso banco de dados passou por um processo de normalizao dos dados,
dificilmente teremos uma tabela sem pelo menos um ndice primrio (PK). Mas mesmo assim, o SQL
Server, poder achar que menos custoso, acessar o dado de uma tabela, realizando uma
varredura fsica, do que ter que acessar a pgina de ndices para recuperar a informao. Isso
poder acontecer em tabelas com pequenas quantidades de dados.
No SQL Server, temos 2 tipos de ndices:
ndices Clusterizados (Clustered Indexes)
ndices No Clusterizados (Nonclustered Indexes)
O ndice clusterizado, um ndice gerado na prpria estrutura de armazenamento dos dados, pois
esse ndice, far com que os dados da sua tabela, fiquem organizados fisicamente na sequencia.
Por esse motivo, s podemos ter 1 (um) ndice clusterizado por tabela. E em qual coluna devemos
criar ndices clusterizados? Bom, por padro, quando criamos uma PK, ela criada
automaticamente como clustered index. Porm, sempre devemos analisar caso a caso. Se para
acessar os dados daquela tabela, voc sempre procura os dados atravs da chave primria, eu
recomendo que voc deixe essa PK como ndice clusterizado. Porm se voc procura os dados
daquela tabela atravs de uma coluna data, por exemplo, recomendo que o ndice seja criado nessa
coluna data. Mas veja bem, sempre temos que analisar e conhecer bem o ambiente para definirmos
qual a melhor coluna para criarmos o ndice clusterizado.
O ndice no clusterizado, um ndice criado em uma estrutura separada dos dados fsicos. So
criadas pginas de ndices que iro conter os apontamentos para os registros fsicos. eficiente
quando precisamos ter vrias maneiras de pesquisa de dados dentro de uma tabela. Por exemplo,
15
uma tabela que contm os livros de uma livraria,armazenamos o nome do livro, o ISBN, o autor, a
editora. Quando pesquisamos um livro, poderemos pesquisar por qualquer uma dessas colunas,
nesse caso, precisaremos ter ndices para cada uma das colunas, ento criaremos ndices nonclustered nessas colunas.
Legal, ento depois que criamos os ndices, ns teremos os acessos aos dados muito mais rpidos e
no teremos mais problemas de lentido? Errado!!! Esse um dos maiores mitos na rea de banco
de dados. Os ndices precisam sempre ser avaliados, desfragmentados e as vezes at recriados. No
caso do SQL Server, quando criamos um ndice, temos uma opo chamada Fill Factor. Esse cara
determina a quantidade de espao em branco que deveremos deixar dentro das pginas de ndices,
para que o SQL Server possa inserir novos apontamentos ali, respeitando a ordenao daquele
ndice. Mas e se no existir espao nas pginas de ndices? Ele ir criar novas paginas, porm no
seguindo a ordenao, a teremos uma fragmentao do ndice. Vamos a um exemplo prtico para
entendimento:
Em uma biblioteca temos uma estante que armazena livros. Essa estante tem 5 prateleiras, e
armazena os livros da letra A at a letra E, distribuidos uniformemente entre as prateleiras. Se no
deixarmos um espao entre as letras A e B, quando chegarem novos livros da letra A, ns seremos
obrigados a colocar esses livros no prximo espao disponvel, no deixando assim uma sequencia
lgica dos livros da letra A. Agora, se deixarmos um espao vazio entre as letras A e B, quando
chegarem novos livros da letra A, poderemos armazen-los sequencialmente, e assim, manter a
ordem lgica dos livros. Pois ento, esse espao em branco justamente o Fill Factor.
O Fill Factor um fator de preenchimento das pginas de ndices. Nesse caso se definirmos um fill
factor = 70%, o SQL Server entender que dever preencher a pagina de ndices, com 70% de sua
capacidade total, deixando 30% para novos apontamentos que surgiro nos inserts e updates que
viro.
Beleza Lo, mas e quando for preenchido esses 30%, o SQL Server vai parar de inserir
apontamentos naquele ndice? No. A, ele ir armazenar os novos apontamentos em uma nova
pgina de ndice ou no prximo espao disponvel que encontrar. Dessa forma teremos a
fragmentao. A onde entra o que citei de sempre avaliar os ndices. Nessas ocasies,
deveremos desfragmentar ou reorganizar o ndice, ou at mesmo recri-lo. No momento da
recriao ou reorganizao, ele novamente criar pginas com no mximo 70% de preenchimento,
deixando espaos para novos apontamentos que viro.
E como sei quanto tenho que colocar no fill factor? Monitorando o banco de dados. Se voc tem
tabelas com grandes incidncias de inserts e updates, provvel que tenha que usar um valor mais
baixo de fill factor, mas em tabelas estticas, que raramente so inseridos novos dados, podemos
deixar o valor do fill factor alto. Outra coisa que voc precisa levar em considerao, a janela de
manuteno dos seus ndices, ou seja, o perodo em que voc pode executar rotinas de
reorganizao dos seus ndices. Tudo isso precisa ser analisado no momento de definio do fill
factor.
ndices Parte 3
Ol, nesse artigo falaremos sobre ndices no MySQL.
Como pudemos ver nos artigos anteriores, os ndices so apontamentos estruturados
organizacionalmente, que indicam o local para acesso aos dados das estruturas de tabelas fsicas.
Podemos enxergar, que os ndices funcionam como facilitadores para o acesso aos dados das
tabelas. No MySQL no diferente. Criamos ndices para melhorar a performance de acesso a estes
dados. Se no tivermos ndices nas tabelas, cada vez que tentarmos localizar algum dado, o engine
do MySQL ir percorrer fisicamente todos os registros da tabela, afim de encontrar os registros
relevantes.
No MySQL os ndices so armazenados em uma estrutura separada dos dados fsicos das tabelas,
chamados de B-tree ou rvore B. No caso de colunas com tipos de dados string, esses so
automaticamente compactados nos espaos finais e prefixados. Os ndices no MySQL podem ser
Primary, Unique e Index.
O tipo Index ou ndice normal, so ndices bsicos. No possuem qualquer tipo de restrio, como
unicidade e podem ser criados em colunas que podemos utilizar nas clausulas where e/ou group by.
Os ndices Primary, como o prprio nome diz, so a chave primria. A particularidade desse ndice,
que s poderemos ter um nico ndice desse tipo por tabela.
Os ndices Unique, so idnticos aos ndices normais, porm utilizamos esses ndices com o intuito
de no poder repetir os valores da coluna, ou seja, pra que elas tenham valores nicos.
A partir da verso 3.23.23 do MySQL, tambm podemos criar ndices do tipo FULL TEXT. Esses
ndices so utilizados para pesquisas textuais. Esse tipo de ndice, somente suportado em tabelas
do tipo MyISAM, e em tipos de colunas CHAR, VARCHAR e TEXT.
Como em todos os SGDBs (Sistemas Gerenciadores de Banco de Dados), precisamos ter alguns
cuidados ao criar ndices. Primeiro, precisamos ter a certeza que aquele ndice ser realmente
utilizado em nossas consultas ou atualizaes. Lembrem-se, o ndice tambm poder ser o
causador de alguma lentido, pois ao inserir, atualizar ou deletar informaes das tabelas, as
estruturas de ndices tambm sero atualizadas.
At o prximo artigo
17