Apelido

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:

Ó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.