Ändra kolumnnamn

Vi måste också ta itu med kolumnnamnen. Annars upprepar vi namnen namn och id, men de innehåller olika data. Å andra sidan finns det den första id-kolumnen och kolumnen för anställda_id, som innehåller samma data.

Låt oss skriva en fråga, där det bara finns de nödvändiga kolumnerna, och även byta namn på kolumnerna med samma namn:

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

Och resultatet av denna fråga:

uppgifts-id task_desc deadline emploee_id emp_name emp_occupation
1 Fixa en bugg på frontend 2022-06-01 1 Ivanov Ivan Programmerare
2 Fixa en bugg på backend 2022-06-15 2 Petrov Petr Programmerare
7 Njut av livet (NULL) 4 Rabinovich Moisha Direktör
3 Köp kaffe 2022-07-01 5 Kirienko Anastasia Kontors chef
4 Köp kaffe 2022-08-01 5 Kirienko Anastasia Kontors chef
5 Köp kaffe 2022-09-01 5 Kirienko Anastasia Kontors chef
8 Njut av livet (NULL) 6 Vaska katt

Bra, problemet med obegripliga kolumnnamn har lösts framgångsrikt. Frågan har blivit lite lång, men allt är klart i den resulterande tabellen. Och inga extra kolumner.

Tabellalias

Ibland är tabellnamnen för långa och tar upp mycket utrymme i frågan. Därför erbjöd skaparna av SQL, för att förbättra läsbarheten, som i fallet med kolumner, möjligheten att ange tabellalias.

Den allmänna formen av alias (tabellalias) är följande:

FROM table1 alias1, table2 alias2

Låt oss skriva om vår tidigare fråga med korta alias:

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äsbarheten har minskat något, men det beror på att namnen på tabellerna från början var enkla och tydliga. Det kan lika gärna vara så här:

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 

Och i det här fallet är alias redan användbara, eller hur? ;)

primärnyckel

Och ytterligare en viktig information om tabeller. Kommer du ihåg att vi hade en anställd_id-kolumn i uppgiftstabellen? Med den hänvisade vi till anställd-ID från anställdstabellen.

Om vi ​​vill hänvisa från en tabell till raderna i en annan tabell, så måste den refererade tabellen ha en kolumn med ett ID, som också kallas primärnyckeln - PRIMÄRNYCKEL .

Oftast är detta en speciellt tillagd kolumn vars värdetyp är int . När du lägger till poster i en tabell ställer SQL automatiskt in värdet för denna kolumn.

Sedan är många saker knutna till dessa nycklar:

  • länka olika tabeller till varandra;
  • snabb sökning och filtrering efter id;
  • dataintegritet i databasen (inga referenser till icke-existerande id);
  • radera data som ingen hänvisar till;
  • och många många andra.

Förresten, det finns situationer när ett bord har en så kallad naturlig nyckel . Det är när det finns en kolumn vars innehåll antyder unikhet. Till exempel bestämde vi oss för att lägga till i personaltabellen:

  • Ordningen för deras ankomst till företaget;
  • Skattenummer;
  • Passets nummer och serie.

Ibland använder databasdesigners en naturlig nyckel som primärnyckel, men oftast används de separat. När allt kommer omkring kan poster tas bort, ändras och liknande.

Jag antar att du läser berättelser på Internet när stämningsmän hänger upp skulder för hans fullständiga namne på en person? Detta är bara relaterat till konceptet med en unik nyckel. Det är mycket bekvämt för banker och kronofogde att söka efter en person med fullständigt namn och födelseår. Och i 99% av fallen är detta tillräckligt för att identifiera en person.

Men de återstående <1% är fullständiga namne, med samma födelseår. I var och en av oss finns det troligtvis inga sådana människor, men på nationell nivå finns det. I allmänhet, om du skriver programvara eller designar en databas, är det bra att veta att det också kan vara fallet.