Aliaser

Ændring af kolonnenavne

Vi skal også forholde os til kolonnenavnene. Ellers gentager vi navnene navn og id, men de indeholder forskellige data. På den anden side er der den første id-kolonne og kolonnen medarbejder_id, som indeholder de samme data.

Lad os skrive en forespørgsel, hvor der kun vil være de nødvendige kolonner, og også omdøbe kolonnerne med de samme navne:

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

Og resultatet af denne forespørgsel:

Fantastisk, problemet med uforståelige kolonnenavne er blevet løst. Forespørgslen er blevet lidt lang, men alt er klart i den resulterende tabel. Og ingen ekstra kolonner.

Tabel aliaser

Nogle gange er tabelnavne for lange og fylder meget i forespørgslen. Derfor tilbød skaberne af SQL, for at forbedre læsbarheden, som i tilfældet med kolonner, muligheden for at specificere tabelaliasser.

Den generelle form for aliaser (tabelaliaser) er som følger:

FROM table1 alias1, table2 alias2

Lad os omskrive vores tidligere forespørgsel med korte aliaser:

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

Læsbarheden er faldet en smule, men det skyldes, at navnene på tabellerne i starten var enkle og klare. Det kan lige så godt være sådan her:

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 

Og i dette tilfælde er aliaser allerede nyttige, ikke? ;)

primærnøgle

Og endnu en vigtig information om tabeller. Husk, at vi havde en medarbejder_id-kolonne i opgavetabellen? Med det refererede vi til medarbejder-id'et fra medarbejdertabellen.

Hvis vi ønsker at henvise fra en tabel til rækkerne i en anden tabel, så skal den refererede tabel have en kolonne med et ID, som også kaldes den primære nøgle - PRIMARY KEY .

Oftest er dette en specielt tilføjet kolonne, hvis værditype er int . Når du tilføjer poster til en tabel, indstiller SQL automatisk værdien af ​​denne kolonne.

Så er der mange ting knyttet til disse nøgler:

• forbinder forskellige tabeller med hinanden;
• hurtig søgning og filtrering efter id;
• dataintegritet i databasen (ingen referencer til ikke-eksisterende id);
• sletning af data, som ingen henviser til;
• og mange mange andre.

Der er i øvrigt situationer, hvor et bord har en såkaldt naturlig nøgle . Det er, når der er en kolonne, hvis indhold antyder unikhed. For eksempel besluttede vi at tilføje til medarbejdertabellen:

• Rækkefølgen af ​​deres ankomst til virksomheden;
• Skattenummer;
• Passets nummer og serie.

Nogle gange bruger databasedesignere en naturlig nøgle som den primære nøgle, men oftest bruges de separat. Records kan jo slettes, ændres og lignende.

Jeg formoder, at du læser historier på internettet, når fogeder hænger hans fulde navnebrors gæld på en person? Dette er kun relateret til konceptet om en unik nøgle. Det er meget bekvemt for banker og fogeder at søge efter en person ved fulde navn og fødselsår. Og i 99% af tilfældene er dette nok til at identificere en person.

Men de resterende <1% er fulde navnebrødre med samme fødselsår. I hver enkelt af os er der højst sandsynligt ingen sådanne mennesker, men på nationalt plan er der. Generelt, hvis du skriver software eller designer en database, så er det nyttigt at vide, at dette også kan være tilfældet.