Proponha uma correção, faça uma sugestão
Vamos dar uns toques em queries SQL? II
No Sábado passado lançamos o primeiro artigo sobre SQL (Structured Query Language) e, segundo os comentários dos nossos leitores, esta é uma rubrica para dar continuidade e desde já contamos com a colaboração de todos os nossos leitores e entendidos na matéria.
Para quem só agora se apercebeu da nossa nova rubrica sobre SQL e não tem qualquer conhecimento sobre esta linguagem, aconselhamos a lerem o nosso primeiro artigo sobre esta matéria (ver aqui).
Depois de no último artigo termos apresentado o comando SELECT, hoje vamos conhecer a cláusula WHERE.
A cláusula WHERE, em conjunto com o comando SELECT permite filtrar um conjutno de informação de uma ou várias tabelas.
Sintaxe de utilização
SELECT nome coluna(s) FROM nome_tabela WHERE nome_coluna operador valores |
Para o presente exemplo, decidi criar uma base de dados com o nome db_pplware e com uma tabela com o nome tbl_pplware com os seguintes campos e dados:
Vamos a alguns exemplos práticos:
EXEMPLO 1
Objectivo: Apresentar toda a informação, das pessoas que vivem em Viseu
Query: SELECT * FROM tbl_pplware WHERE morada='Viseu'
Resultado:
EXEMPLO 2
Objectivo: Apresentar o nome e idade das pessoas que têm cabelo castanho
Query: SELECT nome, idade FROM tbl_pplware WHERE cor_cabelo='castanho'
Resultado:
Alguns operadores que podem ser usados em conjunto com a clausula WHERE.
EXEMPLO 3
Objectivo: Apresentar o nome das pessoas que idade superior a 26 anos
Query: SELECT nome from tbl_pplware WHERE idade > 26
Resultado:
EXEMPLO 4
Objectivo: Apresentar toda a informação das pessoas que tenham “in” no nome
Query: SELECT * FROM tbl_pplware WHERE nome LIKE '%in%'
Resultado:
Esperamos que tenham compreendido a utilização da clausula WHERE e caso tenham alguma dúvida/ideia não hesitem em colocar nos comentários. Não se esqueçam que caso pretendam colaborar nesta rubrica, basta enviarem-me um e-mail para ppinto @ pplware.com.
Artigos relacionados
Este artigo tem mais de um ano
Loading ...
Espectacular 🙂
PPlware sempre em grande, pessoal continuem assim, venho tdos os dias ao vosso site, vezes sem conta 😉
Não conhecia o operador BETWEEN. É o pplware rendendo conhecimentos!
Excelente post.
Falta o IN que tambem pode ser utilizado no where
pode, mas não se deve 🙂
e o like tb não se deve usar, já agora 🙂
não se deve, mas ….pode ter que se usar em casos excepcionais 🙂
cmps
Não se deve usar o IN?
Se querem uma coisa mais dinâmica podem (e devem) usar o IN, tudo depende da situação.
Se querem restringir um select a um determinado grupo de valores de uma tabela, ou até mesmo da própria tabela, podem usar um IN.
Como exemplo, se tiverem uma tabela de clientes em que os códigos postais estão indicados por um código próprio e tiverem outra tabela só para códigos postais, com descrições e isso, se quiserem pesquisar clientes para um determinado código postal devem usar o IN:
select *
from tab_clientes
where id_codpos in (select id_codpos
from tab_cp
where codpos = 2755)
E há “n” casos onde isto faz sentido.
Porque não se deve utilizar o like?
Eu só utilizo o like para efectuar pesquisas…
Existe outra forma para fazer isso?
Cumps
O like é bom na criação de tabelas para definir RIA’s, por exemplo, para que o campo sexo só possa levar as letras “M” ou “F”.
Boas…
a resposta é simples…já viste o que é fazer pesquisas por strings???
cmps
Deves pensar que maior parte das bd das grandes empresas por ai é tudo com índices numéricos … Era bom era 😛
boas..
claro que o desejável era isso acontecer, mas já pensas-te porque é que as pessoas na empresa teem um numero e porque teem um numero de BI????
por acaso na altura ainda não havia bd’s informáticas, mas porque será que tinham um numero de bi????
deves tentar ao máximo usar um ID único obviamente senão não dá :).
cmps
yap a questão é mesmo como é que obtens esse ID único correspondente a pessoa . Alem disso infelizmente garanto te que não e difícil encontrares nas bd campos como o NIF em formato alphanumerico
Muito basicamente, porque é uma instrução muito ‘pesada’.
O que não quer dizer que não o uses para queries pontuais. Agora em ambientes de Produção, integrados em programas, esquece.
Então que instrução devo de utilizar para pesquisar por nome ou parte do nome, numa tabela com 3 campos,
ID, NOME, TELEFONE.
Boas…a questão é mesmo essa…
deves evitar pesquisas por nome, e tentar usar por exemplo id…
cmps
tens que pesquisar por nome em muitas situações , essa será sempre uma delas. Mesmo que tenhas uma dimensão que ligue cada utilizador unico a um id , para obteres o mesmo tens que pesquisar pelo nome
boas…se não houver normalização o id constara na tabela, logo…
cmps
Depende. Num AS/400 fazes uma query dessas a um ficheiro com uns poucos milhões de registos e o resultado não te demora mais de 4 ou 5 segundos num dia mau 😛
ui, e se for numa mainframe então 🙂
mas estamos a falar de BD’s, né 🙂
Yup, DB2 neste caso 🙂
depende…
se o teu servidor tiver a servir 6 mil pessoas ligadas sempre a pedir dados demora 4-6 segundos???…e se a query que fizes-te esgotar a capacidade do servidor que tens…que vais dizer a todos os users que afinal estavam a alterar coisas na base de dados e agora…
cmps
Eu dei um exemplo, nunca disse que isso era o cenário normal 😉
E há políticas de acesso, boas práticas e toda uma panóplia de ideias e conceitos que se aplicam de forma proporcional ao negócio em questão. Para acessos dessa ordem de grandeza, geralmente por webservices, as bases de dados são desenhadas com esse tipo de output em mente e, como tal, a sua performance é melhorada nesse sentido.
Além de que depois tens índices, ficheiros lógicos (também conhecidos como “views”) e outros recursos que tais.
Agora só faltam mesmo uns inner join, outer join, left join, unions… coisas interessantes :p
Gostei muito dos 2 ‘tutoriais’ até agora, mas já estão a assumir que a pessoa tem conhecimentos de teoria de bases de dados, que é em grande parte o pecado dos tutoriais deste género. Nessa onda, também era fixe falar da sintaxe de criação de tabelas, chaves primárias e estrangeiras e explorar bem as relações 1:1, 1:N, M:N… quem sabe até obrigatoriedade, generalizações e RIA’s. Se esses conceitos estão bem assentes na pessoa que cria a base de dados, vai conseguir produzir bd’s muito melhor estruturadas 🙂
Continuação deste excelente artigo!
Cumprimentos
Boas…
queres tu dizer modelos entidade associação… 🙂
cmps
Não só. Esta a falar da normalização das tabelas mas esses são conceitos que não são tão básicos para explicar num tuto.
modelo entidade-associação, modelo relacional… o que quero dizer é que muitos dos que começam ou que já trabalham em SQL ou BD’s na sua generalidade pecam por falta de consolidação destes conhecimentos
Boas..
concordo plenamente, em parte até percebo o porquê de a malta não alinhar muito no modelo entidade associação, é realmente muita filosofia 🙂 , mas melhor que nenhum outro descreve perfeitamente um sistema relacional de bases de dados…
Considero as normalizações importantes, mas não tão importantes como o modelo entidade associação, pois estas só devem ser usadas depois de termos o modelo criado…
Do meu ponto de vista também acho que não devemos abusar nas normalizações, pois as normalizações levam a perdas de performance na base de dados.
O ideal será construir um bom modelo entidade associação, por forma a que não haja repetição de informação etc, e depois normalizar o que resta, mas para mim na maioria dos casos até 3FN, e apenas nas tabelas e entidades fracas que precisem mesmo, nos outros casos para evitar degradação de performance acho que devemos não abusar dela..
just my two cents…
lmx, concordo completamente contigo em ter um bom MEA e normalizar não mais que até à 3ª FN. Sem dúvida que um bom MEA é suficiente para criar a BD. Se bem que acho que a transformação MEA para MR tem mais que se lhe diga 😉
De qualquer forma e enquanto formador, noto que esses conceitos que tu definiste como importantes ficam muito aquém da compreensão nos iniciantes e às vezes até mesmo em quem supostamente já “domina”.
Outro ponto muito importante são as generalizações, para aqueles casos em que é necessário definir categorias e sub-categorias e sub-sub-categorias, que trazem sempre tantas dores de cabeça aos menos experientes.
Boas…
sim, concordo plenamente, a passagem do modelo EA para o relacional, …é uma confussão 🙂 não nos casos mais simples, estes são directos,e passado algum tempo ja se percebe como a coisa funciona, o problema é quando surge um esquema mais complicado e ai dá dores de cabeça, concordo 🙂 .
Eu não posso dizer que sou expert no assunto, apenas que sou dedicado 😉 …
Eu ja tive problemas devido á má construção do MEA, em que posteriormente nem conseguia colocar dados nas tabelas devido aos “loops” de restrições que tinha criado(isto quando comecei a mexer na coisa 🙂 ), hoje ja não me deixo “apanhar na curva” com a mesma facilidade, mas estas coisas a malta so as apanha ganhando background, mexendo na coisa, eu ainda estou longe de me considerar um bom DBA, demoro muito tempo ainda a criar uma base de dados, mas tenho preocupações que não vejo em outros colegas, e que mais tarde alguém vai pensar nelas, mas nessa altura com a info que a bd ja tem e com constantes alterações diarias…já ninguém se atreve a alterar :), só se não houver escapatória…. as coisa teem que ser bem pensadas logo ao inicio e mesmo promenores menos relevantes devem ser tomados em conta, pois no futuro quem sabe não vamos cair nessas situações…O modelo de negócio do cliente altera-se/ou não com o passar do tempo e temos que pensar nisso também.
No entanto como alguém ja tinha aqui falado acho que se devia começar pelo MEA, mas o problema é que para perceber o modelo EA a malta vai partir a cabeça de tanto filosofar…não á escapatória possivel…
Eu sou bastante autodidacta, no entanto gosto de artigos sobre o tema, e o pplware esta de parabéns por ter focado este tema tão importante sobre bd`s e sql.
Vocês estão sempre am alta e na maioria das vezes advinham o que a malta quer :).Parabéns
Eu costumo dizer que a 1FN, 2FN e 3FN aprendem-se na escola e são sem duvida importantíssimas no desenvolvimento de base de dados. No entanto, quando começamos a ganhar experiência e especialmente “sensibilidade” de execução, as formas normais são aplicadas de forma “transparente” 🙂
lmx, eu também comecei como auto-didacta. E é para evitar que as pessoas percam tempo e sanidade mental a bater nos mesmos pontos que eu bati quando comecei que parto a cabeça a inventar esquemas e “acções” para tentar incutir alguma “lógica” e sensibilidade para esses pontos que tu falaste que à partida nos escapam os menos experientes ou os menos cuidadosos. É nesse sentido que acho bom bater na tal filosofia 😛 (não tens como lhe escapar muuahaha) e nos MEA’s e isso tudo.
Isto tudo, sem nunca desfazer o excelente trabalho do Pplware, porque conheço algumas pessoas que também são curiosas nestas andanças e é bom poder fornecer-lhes material em português e não em inglês ou brasileiro com terminologias esquisitas xD
Pedro Pinto, é dessa “sensibilidade” que eu falo, imagina se ensinassem isso na escola… ou noutro sítio qualquer 😀
Boas..
sim concordo, a experiencia automatiza os processos…e mais tarde nem nos damos conta, mas estamos a prever situações e a evita-las, logo de inicio. 🙂
cmps
Falando por mim, para já são exemplos bastante básicos, embora para quem esteja a começar agora a ter contacto com queries SQL, este artigo explica bastante bem.
Mais uma rubrica que vou seguir com certeza.