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ć.
GO TO FULL VERSION