Alterando os nomes das colunas
Também precisamos lidar com os nomes das colunas. Caso contrário, repetimos os nomes name e id, mas eles contêm dados diferentes. Por outro lado, existe a primeira coluna id e a coluna employee_id, que contém os mesmos dados.
Vamos escrever uma consulta, onde haverá apenas as colunas necessárias, e também renomear as colunas com os mesmos nomes:
SELECT
task.id AS task_id,
task.name AS task_desc,
task.deadline AS deadline,
emploee.id AS emploee_id,
emploee.name AS emp_name,
emploee.occupation AS
emp_occupation
FROM employee, task
WHERE emploee.id = task.emploee_id
E o resultado desta consulta:
task_id | task_desc | prazo final | id_funcionário | emp_name | emp_ocupação |
---|---|---|---|---|---|
1 | Corrigir um bug no front-end | 01/06/2022 | 1 | Ivanov Ivan | Programador |
2 | Corrigir um bug no back-end | 15/06/2022 | 2 | Petrov Petr | Programador |
7 | Aproveite a vida | (NULO) | 4 | Rabinovich Moisha | Diretor |
3 | comprar café | 01/07/2022 | 5 | Kirienko Anastácia | Gerente |
4 | comprar café | 01/08/2022 | 5 | Kirienko Anastácia | Gerente |
5 | comprar café | 01/09/2022 | 5 | Kirienko Anastácia | Gerente |
8 | Aproveite a vida | (NULO) | 6 | Vaska | gato |
Ótimo, o problema com nomes de colunas incompreensíveis foi resolvido com sucesso. A consulta ficou um pouco longa, mas tudo está claro na tabela resultante. E sem colunas extras.
Aliases de tabela
Às vezes, os nomes das tabelas são muito longos e ocupam muito espaço na consulta. Portanto, os criadores do SQL, para melhorar a legibilidade, como no caso das colunas, ofereceram a possibilidade de especificar aliases de tabelas.
A forma geral de aliases (aliases de tabela) é a seguinte:
FROM table1 alias1, table2 alias2
Vamos reescrever nossa consulta anterior com aliases curtos:
SELECT
t.id AS task_id,
t.name AS task_desc,
t.deadline AS deadline,
e.id AS emploee_id,
e.name AS emp_name,
e.occupation AS emp_occupation
FROM employee e, task t
WHERE e.id = t.emploee_id
A legibilidade diminuiu um pouco, mas isso ocorre porque os nomes das tabelas eram inicialmente simples e claros. Também pode ser assim:
SELECT
task.id AS task_id,
task.name AS task_desc,
task.deadline AS deadline,
emploee.id AS emploee_id,
emploee.name AS emp_name,
emploee.occupation AS
emp_occupation
FROM
Microsoft_it_department_employee employee,
Year2022_priority_task task
WHERE emploee.id = task.emploee_id
E neste caso, os aliases já são úteis, certo? ;)
chave primária
E mais uma informação importante sobre tabelas. Lembra que tínhamos uma coluna employee_id na tabela de tarefas? Com ele, referenciamos o ID do funcionário da tabela de funcionários.
Se quisermos referenciar de uma tabela para as linhas de outra tabela, a tabela referenciada deve ter uma coluna com um ID, que também é chamada de chave primária - PRIMARY KEY .
Na maioria das vezes, essa é uma coluna especialmente adicionada cujo tipo de valor é int . Ao adicionar registros a uma tabela, o SQL define automaticamente o valor dessa coluna.
Então, muitas coisas estão ligadas a essas chaves:
- vincular tabelas diferentes umas às outras;
- busca rápida e filtragem por id;
- integridade dos dados no banco de dados (sem referências a id inexistente);
- excluir dados aos quais ninguém se refere;
- e muitos outros.
A propósito, há situações em que uma tabela possui a chamada chave natural . É quando há uma coluna cujo conteúdo implica exclusividade. Por exemplo, decidimos adicionar à tabela de funcionários:
- A ordem de chegada na empresa;
- Número de identificação fiscal;
- Número e série do passaporte.
Às vezes, os designers de banco de dados usam uma chave natural como chave primária, mas na maioria das vezes elas são usadas separadamente. Afinal, os registros podem ser excluídos, alterados e assim por diante.
Suponho que você leia histórias na Internet quando oficiais de justiça penduram dívidas de seu homônimo completo em uma pessoa? Isso está relacionado apenas ao conceito de uma chave exclusiva. É muito conveniente para bancos e oficiais de justiça procurar uma pessoa pelo nome completo e ano de nascimento. E em 99% dos casos isso é suficiente para identificar uma pessoa.
Mas os restantes <1% são homônimos completos, com o mesmo ano de nascimento. Na vida de cada um de nós, provavelmente não existem tais pessoas, mas em escala nacional, existem. Em geral, se você estiver escrevendo um software ou projetando um banco de dados, é útil saber que esse também pode ser o caso.
GO TO FULL VERSION