Alias

Modification des noms de colonne

Nous devons également nous occuper des noms de colonnes. Sinon, on répète les noms name et id, mais ils contiennent des données différentes. D'autre part, il y a la première colonne id et la colonne employee_id, qui contiennent les mêmes données.

Écrivons une requête, où il n'y aura que les colonnes nécessaires, et renommez également les colonnes avec les mêmes noms :

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

Et le résultat de cette requête :

Super, le problème des noms de colonnes incompréhensibles a été résolu avec succès. La requête est devenue un peu longue, mais tout est clair dans le tableau résultant. Et pas de colonnes supplémentaires.

Alias ​​de table

Parfois, les noms de table sont trop longs et occupent beaucoup d'espace dans la requête. Par conséquent, les créateurs de SQL, pour améliorer la lisibilité, comme dans le cas des colonnes, ont offert la possibilité de spécifier des alias de table.

La forme générale des alias (alias de table) est la suivante :

FROM table1 alias1, table2 alias2

Réécrivons notre requête précédente avec des alias courts :

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

La lisibilité a légèrement diminué, mais c'est parce que les noms des tables étaient initialement simples et clairs. Ça pourrait aussi bien être comme ça :

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 

Et dans ce cas, les alias sont déjà utiles, non ? ;)

clé primaire

Et une autre information importante sur les tables. Vous souvenez-vous que nous avions une colonne employee_id dans la table des tâches ? Avec lui, nous avons référencé l'ID de l'employé à partir de la table des employés.

Si nous voulons faire référence d'une table aux lignes d'une autre table, la table référencée doit avoir une colonne avec un ID, également appelée clé primaire - PRIMARY KEY .

Le plus souvent, il s'agit d'une colonne spécialement ajoutée dont le type de valeur est int . Lors de l'ajout d'enregistrements à une table, SQL définit automatiquement la valeur de cette colonne.

Ensuite, beaucoup de choses sont liées à ces clés :

• relier différentes tables les unes aux autres ;
• recherche rapide et filtrage par identifiant ;
• l'intégrité des données dans la base de données (aucune référence à un identifiant inexistant) ;
• supprimer les données auxquelles personne ne se réfère ;
• et bien d'autres.

Soit dit en passant, il existe des situations où une table a une clé dite naturelle . C'est quand il y a une colonne dont le contenu implique l'unicité. Par exemple, nous avons décidé d'ajouter à la table des employés :

• L'ordre de leur arrivée dans l'entreprise ;
• Numéro d'identification fiscale;
• Numéro et série du passeport.

Parfois, les concepteurs de bases de données utilisent une clé naturelle comme clé primaire, mais le plus souvent, elles sont utilisées séparément. Après tout, les enregistrements peuvent être supprimés, modifiés, etc.

Je suppose que vous avez lu des histoires sur Internet lorsque des huissiers suspendent les dettes de son homonyme complet à une personne ? Ceci est simplement lié au concept de clé unique. Il est très pratique pour les banques et les huissiers de rechercher une personne par nom, prénom et année de naissance. Et dans 99% des cas, cela suffit pour identifier une personne.

Mais les <1% restants sont des homonymes complets, avec la même année de naissance. Dans la vie de chacun de nous, il n'y a probablement pas de telles personnes, mais à l'échelle nationale, il y en a. En général, si vous écrivez un logiciel ou concevez une base de données, il est utile de savoir que cela peut également être le cas.