Zmiana nazw kolumn

Musimy także zająć się nazwami kolumn. W przeciwnym razie powtarzamy nazwy name i id, ale zawierają one inne dane. Z drugiej strony jest pierwsza kolumna id i kolumna id_pracownika, które zawierają te same dane.

Napiszmy zapytanie, w którym będą tylko niezbędne kolumny, a także zmieńmy nazwy kolumn na te same nazwy:

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

I wynik tego zapytania:

identyfikator_zadania opis_zadania termin ostateczny identyfikator_pracownika nazwa_pracy zawód_zatrudniony
1 Napraw błąd w interfejsie użytkownika 2022-06-01 1 Iwanow Iwan Programista
2 Napraw błąd w backendzie 2022-06-15 2 Pietrow Pietr Programista
7 Ciesz się życiem (ZERO) 4 Rabinowicz Mojsza Dyrektor
3 Kup kawę 2022-07-01 5 Kirienko Anastazja Kierownik biura
4 Kup kawę 2022-08-01 5 Kirienko Anastazja Kierownik biura
5 Kup kawę 2022-09-01 5 Kirienko Anastazja Kierownik biura
8 Ciesz się życiem (ZERO) 6 Vaska kot

Świetnie, problem z niezrozumiałymi nazwami kolumn został pomyślnie rozwiązany. Zapytanie stało się trochę długie, ale w wynikowej tabeli wszystko jest jasne. I bez dodatkowych kolumn.

Aliasy tabeli

Czasami nazwy tabel są zbyt długie i zajmują dużo miejsca w zapytaniu. Dlatego twórcy SQL, aby poprawić czytelność, podobnie jak w przypadku kolumn, zaoferowali możliwość określenia aliasów tabeli.

Ogólna postać aliasów (aliasów tabel) jest następująca:

FROM table1 alias1, table2 alias2

Przepiszmy nasze poprzednie zapytanie z krótkimi aliasami:

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

Czytelność nieco spadła, ale to dlatego, że nazwy tabel były początkowo proste i czytelne. Równie dobrze może być tak:

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 

I w tym przypadku aliasy są już przydatne, prawda? ;)

główny klucz

I jeszcze jedna ważna informacja o stołach. Pamiętasz, że w tabeli zadań mieliśmy kolumnę id_pracownika? Za jego pomocą odwołaliśmy się do identyfikatora pracownika z tabeli pracowników.

Jeśli chcemy odwoływać się z jednej tabeli do wierszy innej tabeli, to tabela, do której się odwołujemy, musi mieć kolumnę z identyfikatorem, który jest również nazywany kluczem podstawowym – PRIMARY KEY .

Najczęściej jest to specjalnie dodana kolumna, której typem wartości jest int . Podczas dodawania rekordów do tabeli SQL automatycznie ustawia wartość tej kolumny.

Następnie wiele rzeczy jest powiązanych z tymi kluczami:

  • łączenie ze sobą różnych tabel;
  • szybkie wyszukiwanie i filtrowanie po id;
  • integralność danych w bazie danych (brak odniesień do nieistniejącego id);
  • usuwanie danych, do których nikt się nie odnosi;
  • i wiele wiele innych.

Nawiasem mówiąc, zdarzają się sytuacje, gdy tabela ma tzw. klucz naturalny . Dzieje się tak, gdy istnieje kolumna, której zawartość sugeruje wyjątkowość. Na przykład zdecydowaliśmy się dodać do tabeli pracowników:

  • Kolejność ich przybycia do firmy;
  • Numer identyfikacji podatkowej;
  • Numer i seria paszportu.

Czasami projektanci baz danych używają klucza naturalnego jako klucza podstawowego, ale najczęściej są one używane oddzielnie. W końcu rekordy można usuwać, zmieniać i tym podobne.

Przypuszczam, że czytasz historie w Internecie, kiedy komornicy wieszają długi jego pełnego imiennika na osobie? Jest to po prostu związane z koncepcją unikalnego klucza. Dla banków i komorników bardzo wygodne jest poszukiwanie osoby po imieniu i nazwisku oraz roku urodzenia. A w 99% przypadków wystarczy to do zidentyfikowania osoby.

Ale pozostałe <1% to pełne imienniki, z tym samym rokiem urodzenia. W życiu każdego z nas takich osób najprawdopodobniej nie ma, ale w skali kraju są. Ogólnie rzecz biorąc, jeśli piszesz oprogramowanie lub projektujesz bazę danych, warto wiedzieć, że tak też może być.