| ID_Pracownika | Nazwisko | Imię | Stanowisko | Wynagrodzenie |
|---|---|---|---|---|
| 1 | Kowalski | Krzysztof | kasjer | 3215,76 |
| 2 | Nowak | Antoni | kierownik | 5350,00 |
| 3 | Zając | Alicja | księgowy | 4568,70 |
| 4 | Król | Witold | kasjer | 3045,00 |
| 5 | Nowik | Grzegorz | kasjer | 2750,65 |
| 6 | Kotulski | Andrzej | kierowca | 3467,00 |
| 7 | Tutka | Katarzyna | kierownik | 4935,33 |
| 8 | Porada | Jakub | magazynier | 3321,56 |
Poprawne zapytanie to SELECT AVG(Wynagrodzenie) FROM Pracownicy WHERE Stanowisko='kasjer';, bo dokładnie robi to, o co chodzi w treści zadania. Funkcja AVG() w SQL jest standardową funkcją agregującą, która liczy średnią arytmetyczną z wartości liczbowych w danej kolumnie. W tym przypadku kolumna to Wynagrodzenie, czyli kwoty wypłat, a klauzula WHERE Stanowisko='kasjer' zawęża zestaw rekordów tylko do pracowników na stanowisku kasjera. Najpierw więc silnik bazy danych filtruje wiersze (kasjerów), a dopiero potem na tej ograniczonej grupie liczy średnią. To jest bardzo typowy i poprawny schemat pracy z danymi w SQL: najpierw filtrujesz, potem agregujesz.
Moim zdaniem warto zauważyć, że taka konstrukcja jest uniwersalna – w praktyce w firmach często liczy się średnie wynagrodzenia dla różnych stanowisk, działów, lokalizacji. Wtedy zmienia się tylko warunek w klauzuli WHERE. Można też pójść krok dalej i użyć GROUP BY, np. SELECT Stanowisko, AVG(Wynagrodzenie) FROM Pracownicy GROUP BY Stanowisko; żeby dostać średnie dla wszystkich stanowisk naraz, co jest wygodne np. w raportach HR. To, co masz w odpowiedzi, to w zasadzie „wersja jednostanowiskowa” takiego raportu.
Ważna dobra praktyka: zawsze filtrujemy w klauzuli WHERE, a nie próbujemy wpychać warunków do funkcji agregującej. Dzięki temu zapytanie jest czytelne, zgodne ze standardem SQL i dobrze optymalizowane przez silnik bazy. W realnych projektach staramy się też nadać alias wynikom agregacji, np. SELECT AVG(Wynagrodzenie) AS SredniaKasjera FROM Pracownicy WHERE Stanowisko='kasjer';, żeby w raportach i w kodzie aplikacji od razu było wiadomo, co oznacza zwracana kolumna.
Moim zdaniem warto zauważyć, że taka konstrukcja jest uniwersalna – w praktyce w firmach często liczy się średnie wynagrodzenia dla różnych stanowisk, działów, lokalizacji. Wtedy zmienia się tylko warunek w klauzuli WHERE. Można też pójść krok dalej i użyć GROUP BY, np. SELECT Stanowisko, AVG(Wynagrodzenie) FROM Pracownicy GROUP BY Stanowisko; żeby dostać średnie dla wszystkich stanowisk naraz, co jest wygodne np. w raportach HR. To, co masz w odpowiedzi, to w zasadzie „wersja jednostanowiskowa” takiego raportu.
Ważna dobra praktyka: zawsze filtrujemy w klauzuli WHERE, a nie próbujemy wpychać warunków do funkcji agregującej. Dzięki temu zapytanie jest czytelne, zgodne ze standardem SQL i dobrze optymalizowane przez silnik bazy. W realnych projektach staramy się też nadać alias wynikom agregacji, np. SELECT AVG(Wynagrodzenie) AS SredniaKasjera FROM Pracownicy WHERE Stanowisko='kasjer';, żeby w raportach i w kodzie aplikacji od razu było wiadomo, co oznacza zwracana kolumna.
W tym zadaniu widać kilka typowych pułapek związanych z pisaniem zapytań SQL, zwłaszcza przy funkcjach agregujących. Kluczowa rzecz: jeśli chcemy policzyć średnie wynagrodzenie dla konkretnego stanowiska, to zawsze musimy połączyć poprawną funkcję agregującą z poprawnym filtrowaniem danych. Standard SQL definiuje funkcję AVG() do liczenia średniej, SUM() do sumowania, COUNT() do liczenia wierszy i tak dalej. Nie ma natomiast funkcji o nazwie SREDNIA, bo to byłaby już jakaś specyficzna, niestandardowa funkcja w danej bazie (a w typowych systemach jak MySQL, PostgreSQL, SQL Server czy Oracle po prostu jej nie ma).
Częsty błąd to próba używania nazwy stanowiska jakby była nazwą tabeli lub aliasu, np. coś w stylu AVG(kasjer.Wynagrodzenie). Tu „kasjer” nie jest ani aliasem tabeli, ani osobną tabelą, tylko wartością tekstową w kolumnie Stanowisko. W SQL nie można w ten sposób „kropkować” wartości. Do filtrowania służy klauzula WHERE: Stanowisko='kasjer'. Kolejna rzecz to używanie SUM(*) czy innych funkcji w połączeniu z AND w niewłaściwym miejscu. Wyrażenie typu SELECT SUM(*) FROM Pracownicy AND Stanowisko='kasjer'; jest po prostu składniowo błędne. Warunki logiczne AND, OR, NOT zawsze trafiają do części WHERE lub JOIN ON, a nie między nazwę tabeli a funkcję agregującą.
Inny typowy błąd myślowy to mieszanie logiki zapytania: ktoś próbuje jednocześnie pisać coś w rodzaju SELECT SREDNIA(Wynagrodzenie) AND Stanowisko='kasjer' FROM Pracownicy; jakby można było w jednym miejscu łączyć funkcję i warunek. SQL ma jasno rozdzielone sekcje: SELECT (co zwracamy), FROM (z jakiej tabeli), WHERE (jak filtrujemy), opcjonalnie GROUP BY, HAVING, ORDER BY. Warunek filtrowania nie pojawia się w środku listy wybieranych kolumn, tylko w WHERE. Z mojego doświadczenia wynika, że jak ktoś zaczyna poprawnie myśleć o kolejności wykonywania zapytania (najpierw FROM, potem WHERE, potem agregacja), to takie błędy po prostu znikają. Dobrą praktyką jest też, zanim użyje się funkcji agregującej, zadać sobie pytanie: na jakim dokładnie podzbiorze danych chcę tę funkcję zastosować? I właśnie ten podzbiór trzeba opisać w WHERE.
Częsty błąd to próba używania nazwy stanowiska jakby była nazwą tabeli lub aliasu, np. coś w stylu AVG(kasjer.Wynagrodzenie). Tu „kasjer” nie jest ani aliasem tabeli, ani osobną tabelą, tylko wartością tekstową w kolumnie Stanowisko. W SQL nie można w ten sposób „kropkować” wartości. Do filtrowania służy klauzula WHERE: Stanowisko='kasjer'. Kolejna rzecz to używanie SUM(*) czy innych funkcji w połączeniu z AND w niewłaściwym miejscu. Wyrażenie typu SELECT SUM(*) FROM Pracownicy AND Stanowisko='kasjer'; jest po prostu składniowo błędne. Warunki logiczne AND, OR, NOT zawsze trafiają do części WHERE lub JOIN ON, a nie między nazwę tabeli a funkcję agregującą.
Inny typowy błąd myślowy to mieszanie logiki zapytania: ktoś próbuje jednocześnie pisać coś w rodzaju SELECT SREDNIA(Wynagrodzenie) AND Stanowisko='kasjer' FROM Pracownicy; jakby można było w jednym miejscu łączyć funkcję i warunek. SQL ma jasno rozdzielone sekcje: SELECT (co zwracamy), FROM (z jakiej tabeli), WHERE (jak filtrujemy), opcjonalnie GROUP BY, HAVING, ORDER BY. Warunek filtrowania nie pojawia się w środku listy wybieranych kolumn, tylko w WHERE. Z mojego doświadczenia wynika, że jak ktoś zaczyna poprawnie myśleć o kolejności wykonywania zapytania (najpierw FROM, potem WHERE, potem agregacja), to takie błędy po prostu znikają. Dobrą praktyką jest też, zanim użyje się funkcji agregującej, zadać sobie pytanie: na jakim dokładnie podzbiorze danych chcę tę funkcję zastosować? I właśnie ten podzbiór trzeba opisać w WHERE.