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