Alias jest alternatywną nazwą, której możemy używać do określenia danego obiektu.
Zaczniemy jednak od zbudowania naszej prostej bazy w oparciu o stosowanie przedrostków:
Stosowanie przedrostków w nazwach tabel
Wyobraźmy sobie, że posiadamy prostą bazę złożoną z trzech tabel, która posiada informację na temat projektu, oraz osób realizujących.Zastosujemy przedrostki, które umożliwią nam błyskawiczne określenie, jakie dane przechowuje baza:
- TBL_ - tabele z danymi
- DIC_ - słowniki
| TBL_PROJECT | ||
|---|---|---|
| PK | Project_Id | int |
| ProjectName | nvarchar(100) | |
zawierającą:
| Project_Id | ProjectName |
| 1 | Package Control |
| 2 | Divide by zero system |
| 3 | Fridge Automation |
tabeli z uczestnikami projektu
| TBL_PROJECTCREATOR | ||
|---|---|---|
| PK | Employee_Id | int |
| FK | Project_Id | int |
| Name | nvarchar(100) | |
| Surname | nvarchar(100) | |
| FK | Role_Id | int |
oraz słownika ról:
| DIC_ROLE | ||
|---|---|---|
| PK | Role_Id | int |
| RoleName | nvarchar(100) | |
| Role_Id | RoleName |
| 1 | Project Manager |
| 2 | Team Leader |
| 3 | Tester |
Dzięki takiej strukturze szybko możemy zidentyfikować, czy dane zawarte w tabeli są słownikiem, czy też innymi, czy bardziej "produkcyjnym" zbiorem (w naszym przypadku określającym kto jest przypisany do jakiego projektu, oraz jaką pełni funkcję).
Możemy rozszerzać listę przedrostków zgodnie z naszymi oczekiwaniami (np określając poszczególne podsystemy/moduły), a późniejsze przestrzeganie standardów pomoże w późniejszym odnalezieniu interesujących nas rekordów.
Aliasy
Chcielibyśmy pobrać ogólne informacje na temat projektu, tj:1. nazwa projektu
2. imię i nazwisko project managera
3. imię i nazwisko testera
SELECT
P.ProjectName as [Project Name],
PM.Name + ' ' + PM.Surname as [Project Manager],
Tester.Name + ' ' + Tester.Surname as [Tester]
From TBL_PROJECT P
LEFT JOIN TBL_ProjectCreator PM on P.Project_Id = PM.Project_Id and PM.Role_Id = 1
LEFT JOIN TBL_ProjectCreator Tester on P.Project_Id = Tester.Project_Id and Tester.Role_Id = 3
Zrozumiałym jest, że w takiej sytuacji MUSIELIŚMY skorzystać z aliasów, ponieważ dwukrotnie odnosimy się do tabeli TBL_ProjectCreator i SQL nie wiedziałby, o co nam dokładnie chodzi, do którego joina się odnosimy itd.
Jednak uprościmy formę bez wykorzystania aliasów do pobrania samych danych na temat projektu i osoby testującej:
SELECT
ProjectName as [Project Name],
Name + Surname as [Tester]
FROM TBL_PROJECT
LEFT JOIN TBL_ProjectCreator on TBL_Project.Project_Id = TBL_ProjectCreator.Project_Id and TBL_ProjectCreator.Role_Id = 3
Oczywiście kod zadziała, jednak zmniejsza się czytelność zapytania. Ponadto jeśli pojawi się konflikt nazw z różnych tabel (przykładowo "ID" stosowane we wszystkich tabelach z taką samą nazwą, co jest jak najbardziej dozwolone - ale odradzam :) ), musimy powiedzieć kochanemu SQL'owi, z której dokładnie tabeli chcemy teraz wyświetlić rekordy. Bez aliasów - operujemy na pełnych nazwach.
Ograniczenia i "dobre praktyki"
Jest kilka podstawowych ograniczeń związanych z aliasami, oraz dobrych- Nie możemy użyć takiego samego aliasu do różnych tabel (wówczas ich stosowanie nie miałoby najmniejszego sensu)
- Powinniśmy stosować raczej proste aliasy, np User. , Tester. , PM. , Contact. , etc.
- powinniśmy unikać stosowania nic nie znaczących aliasów typu X. , Y. , U1. , U2.
Podsumowanie
Zastosowanie aliasów przy zapytaniach przynosi korzyści w postaci:- Ograniczenia długości zapytania (oczywiście nie zawsze - np jeśli zastosujemy bardziej wykwintne aliasy), w tym skrócenia zapytań również w przypadku stosowania wielu schem (innych niż domyślnego dbo. )
- Poprawy czytelności zapytań
- przy pewnym poziomie generalizacji danych (jak w przykładzie z uczestnikami projektu, którzy mają przypisane role; nie są "rozdzieleni" na różne tabele) - bezpośrednią identyfikację podmiotów (jak w przykładzie - aliasy PM oraz TESTER)
Zachęcam również do stosowania przedrostków przy nazewnictwu tabel, niezależnie od tego czy składa się z pięciu, czy kilku tysięcy tabel. Zachowanie porządku w danych jest niezwykle ważne, nie tylko na etapie jej projektowania, ale również podczas obsługi i "prac codziennych".
