Od Excela do SQL: jak zacząć pracę z bazami danych krok po kroku

Skąd pomysł, żeby przejść z Excela na SQL

Kiedy Excel zaczyna się dławić danymi

Każdy, kto pracuje z Excelem dłużej niż kilka miesięcy, prędzej czy później trafia na moment, w którym plik otwiera się wieczność, zmiana jednego filtra trwa pół minuty, a zapis pliku potrafi zawiesić komputer. Arkuszy przybywa, formuły robią się coraz bardziej złożone, tabele przestawne liczą się dłużej niż kawa stygnie na biurku.

Typowy scenariusz: raport miesięczny powstał kiedyś jako prosty arkusz. Z czasem dołożyły się kolejne zakładki: rok poprzedni, zestawienie kwartalne, import z systemu, kopia bezpieczeństwa, „wersja_ostateczna_v4_poprawiona”. Wszystko nadal działa, ale:

• plik ma dziesiątki megabajtów i otwiera się kilka minut,
• każda zmiana formuły potrafi przeliczać się wiecznie,
• łatwo coś przypadkiem nadpisać lub usunąć,
• nikt już nie pamięta, która zakładka jest źródłem prawdy.

W tym momencie pojawia się myśl: „Przecież to może działać lepiej”. I tutaj wchodzi SQL – język do pracy z bazami danych, który robi to, co Excel, ale dla dużo większych, wspólnych, lepiej kontrolowanych zbiorów danych.

Dlaczego specjaliści różnych działów dochodzą do SQL

SQL nie jest zabawką wyłącznie dla programistów. Z baz danych korzystają:

• analitycy biznesowi – gdy raportów nie da się już wyklikać w BI lub Excelu,
• specjaliści HR – gdy dane o pracownikach, rekrutacjach, szkoleniach siedzą w różnych systemach i trzeba je ze sobą powiązać,
• kontrolerzy finansowi – kiedy transakcje liczone w setkach tysięcy wierszy przekraczają komfortowy zakres Excela,
• specjaliści e‑commerce i marketingu – gdy trzeba łączyć dane z systemu sprzedaży, kampanii, magazynu.

Wspólny mianownik? Dane przestają mieścić się w jednym pliku, a praca solo zmienia się w pracę zespołową. Excel nadaje się świetnie do analizy, prototypowania i wizualizacji. SQL natomiast staje się kręgosłupem, na którym wszystko się opiera.

Excel a SQL – bliżej niż do programowania aplikacji

Spora część osób obawia się SQL-a, bo kojarzy go z „poważnym programowaniem”. Tymczasem mentalnie SQL jest bliżej Excela niż Pythona czy Javy. W Excelu mówisz: „Ta komórka ma być sumą tamtych pięciu”. W SQL mówisz: „Zbierz wszystkie wiersze z tej tabeli, przefiltruj je i policz sumę po kolumnie sprzedaż”.

SQL to bardziej język zapytań niż język programowania. Nie budujesz aplikacji – mówisz bazie danych, jakie dane chcesz zobaczyć i w jakiej formie. Dla kogoś, kto pracował w Excelu z filtrami, tabelami przestawnymi i prostymi formułami, wejście w SQL to nie skok na głęboką wodę, tylko przeprowadzka do większego mieszkania.

Co zyskujesz, przechodząc z Excela do SQL

Najważniejsze korzyści pojawiają się niemal natychmiast po tym, jak pierwszy raz zdejmiesz z Excela ciężar bycia „główną bazą danych”:

• wydajność – miliony wierszy liczone w sekundach, nie minutach,
• bezpieczeństwo – uprawnienia, kopie zapasowe, logi zmian,
• praca zespołowa – wielu użytkowników może pracować na tych samych danych bez nadpisywania się,
• jedno źródło prawdy – dane siedzą w bazie, a pliki Excela stają się tylko raportami, nie magazynem wszystkiego.

Excel nie znika. Staje się narzędziem końcowym: do prezentacji, do szybkich analiz, do wykresów. SQL zajmuje się tym, co robiła „brudna robota” w postaci importów, łatania formuł i kopiuj–wklej między plikami.

Excel vs SQL – co jest czym, na ludzkich analogiach

Tabela w Excelu kontra tabela w bazie danych

Na pierwszy rzut oka tabela w Excelu i tabela w SQL wyglądają identycznie: wiersze, kolumny, nagłówki. Jednak pod spodem różnice są spore:

• w Excelu w jednej kolumnie możesz mieć liczby, teksty, daty i puste komórki wymieszane jak w sałatce,
• w SQL każda kolumna ma typ danych – np. liczba, tekst, data – i nie da się wcisnąć tam czegoś „z innej beczki”,
• w bazie możesz ustawić ograniczenia (np. obowiązkowe wypełnienie, unikalność), których Excel sam z siebie nie pilnuje.

Efekt? Dane w SQL są bardziej uporządkowane i spójne. Zamiast zastanawiać się, czy w kolumnie „Data sprzedaży” czasem nie wylądował tekst „b.d.”, masz pewność, że każda komórka to prawidłowa data albo wartość NULL (czyli „brak danych”).

Plik Excela jako odpowiednik bazy danych

Dla kogoś, kto myśli w kategoriach „plików”, przełożenie na SQL wygląda mniej więcej tak:

W Excelu masz często jeden plik na projekt. W SQL możesz mieć jedną bazę na system (np. „Sprzedaż”), a w niej dziesiątki tabel. Zamiast tworzyć pięć plików dla różnych działów, trzymasz dane w jednym miejscu, a każdy dział wyciąga z nich to, czego potrzebuje.

Formuły Excela a zapytania SQL

W Excelu pracujesz głównie na formułach, np.:

• =SUMA(C2:C1000),
• =JEŻELI(A2>100; "duże"; "małe"),
• =WYSZUKAJ.PIONOWO(A2;TabelaZamówień;3;0).

W SQL zamiast formuł piszesz zapytania, np.:

• SELECT SUM(kwota) FROM zamowienia;
• SELECT CASE WHEN wartosc > 100 THEN 'duże' ELSE 'małe' END FROM zamowienia;
• SELECT ... FROM klienci JOIN zamowienia ON klienci.id = zamowienia.id_klienta;

Różnica jest subtelna, ale ważna:

• formułę w Excelu wpisujesz do konkretnej komórki,
• zapytanie SQL piszesz raz i działa na całym zestawie danych.

Można to porównać do różnicy między ręcznym myciem talerzy a włączeniem zmywarki. W Excelu często „idziesz” wiersz po wierszu. W SQL definiujesz, co ma się stać z całą tabelą i baza robi to za Ciebie.

Kopiuj–wklej w Excelu a jedno źródło prawdy w SQL

Excel zachęca do kopiowania danych: „Wyślę Ci ten plik, tylko podmienię tu jedną tabelkę i dodam kolumnę”. Po kilku tygodniach masz pięć prawie identycznych wersji. Która jest poprawna? Nikt nie wie.

SQL działa odwrotnie:

• dane siedzą w jednym miejscu – w bazie,
• różne raporty to różne zapytania, nie kopie danych,
• jeśli dane źródłowe się zmienią, wszystkie raporty oparte na tej bazie pokażą aktualny stan.

Zamiast kopiować arkusze, tworzysz kolejne zapytania lub widoki. Zamiast „Raport_końcowy_v5_poprawiony2.xlsx” masz np. widok raport_sprzedazy_miesiecznej, który zawsze pobiera aktualne dane z tabel sprzedażowych.

Jak zacząć technicznie – wybór i instalacja darmowej bazy SQL

Najpopularniejsze darmowe systemy baz danych

Na starcie pojawia się pytanie: jaką bazę wybrać? Dla początkującego użytkownika Excela liczy się prostota, darmowość i dostępność materiałów. Kilka najpopularniejszych systemów:

• SQLite – ultralekka baza, wszystko w jednym pliku. Idealna do nauki składni SQL, prototypów, małych projektów.
• MySQL / MariaDB – bardzo popularne w projektach webowych. Sporo tutoriali, hostingów, narzędzi.
• PostgreSQL – „szwajcarski scyzoryk” wśród baz. Stabilny, rozbudowany, często używany w analityce i aplikacjach biznesowych.
• SQL Server Express – darmowa edycja Microsoft SQL Server. Naturalny wybór w firmach „microsoftowych”.

Do nauki SQL wystarczy każda z nich. Jeśli w pracy używa się konkretnego systemu, rozsądnie jest uczyć się właśnie na nim. Jeśli nie – często dobrym złotym środkiem jest PostgreSQL lub SQLite (bo są darmowe i proste w instalacji).

Serwer a klient – magazyn i okienko

W świecie SQL często pojawiają się dwa słowa: serwer i klient. Dla osoby z Excela to może brzmieć abstrakcyjnie, a w praktyce chodzi o prostą rzecz.

• Serwer – to „magazyn”: tam fizycznie trzymane są tabele, tam odbywają się obliczenia. Może działać na Twoim komputerze lub na serwerze firmowym.
• Klient – to „okienko w magazynie”: program, w którym wpisujesz zapytania SQL, oglądasz wyniki, przeglądasz tabele.

Przykłady klientów:

• DBeaver – darmowy, działa z wieloma silnikami (PostgreSQL, MySQL, SQL Server i inne),
• Azure Data Studio – świetny do SQL Server,
• pgAdmin – klient dedykowany PostgreSQL,
• SQLiteStudio – prosty klient dla SQLite.

Instalacja zwykle wygląda tak: instalujesz serwer (np. PostgreSQL), potem instalujesz klienta (np. DBeaver), w kliencie dodajesz połączenie do serwera, wpisując adres, port, nazwę bazy i dane logowania.

Szybki start: przykładowy scenariusz instalacji

Przykładowa, prosta ścieżka dla osoby, która nigdy nie instalowała bazy danych (na przykładzie PostgreSQL + DBeaver):

1. Pobierz PostgreSQL z oficjalnej strony (instalator dla Windows / macOS / Linux).
2. Przy instalacji zapamiętaj hasło do użytkownika administracyjnego (np. postgres).
3. Uruchom DBeaver i wybierz „New Database Connection”.
4. Wybierz PostgreSQL z listy, wpisz:
   • Host: localhost
   • Port: domyślnie 5432
   • User: postgres (lub inny, który ustawiłeś)
   • Password: hasło podane przy instalacji
5. Połącz się i zobaczysz listę baz danych po lewej stronie.

W wielu tutorialach znajdziesz gotowe przykładowe bazy (np. „dvdrental” dla PostgreSQL). Warto je wgrać – dzięki temu nie trzeba od razu tworzyć własnych tabel, można od ręki ćwiczyć zapytania.

Proste checklisty na start z bazą SQL

Dobrym nawykiem jest krótkie sprawdzenie, czy wszystko działa:

• Czy serwer bazy działa (usługa jest uruchomiona, klient nie zgłasza błędu połączenia)?
• Czy w kliencie widzisz listę baz, tabel, widoków?
• Czy możesz otworzyć podgląd danych w którejś tabeli (bez pisania SQL)?
• Czy uda się wykonać proste zapytanie typu SELECT 1; albo SELECT NOW();?

Jeśli te kroki przechodzą bez problemu, można przejść do faktycznej pracy z danymi zamiast walki z konfiguracją.

Pierwsze spojrzenie na przykład danych – baza zamiast pliku Excel

Typowy zestaw: klienci, zamówienia, produkty

Wyobraźmy sobie prosty świat sprzedażowy. W Excelu wiele osób trzyma wszystko w jednym arkuszu: klient, jego dane, zamówienie, produkt, cena, ilość, rabat. W SQL taki „arkusz wszechświata” rozbije się na kilka tabel:

Jak te dane rozbić na tabele w SQL

Taki „jednoarkuszowy” Excel jest wygodny na początek, ale szybko zaczyna uwierać: duplikują się dane klientów, produkty wpisywane są z literówkami, rabaty liczysz raz tak, raz inaczej. W SQL ten bałagan można posprzątać, rozdzielając dane na logiczne kawałki:

• klienci – kto kupuje,
• produkty – co jest sprzedawane,
• zamówienia – pojedyncze dokumenty sprzedaży (np. faktury, paragony),
• pozycje_zamowien – linijki w zamówieniu: produkt, ilość, cena.

Brzmi abstrakcyjnie? Spójrz na to jak na segregatory. Jeden segregator to klienci, drugi – katalog produktów, trzeci – teczki z zamówieniami, a w każdej teczce powkładane kartki z pozycjami. W Excelu wszystko jest często „zszyte” w jednym pliku; w SQL każde z tych miejsc dostaje swoją tabelę.

Przykładowe struktury tabel – „szkielet” bazy

Zanim pojawi się SQL, dobrze mieć obraz w głowie, co właściwie ma się w bazie znaleźć. To jest odpowiednik momentu, kiedy w Excelu planujesz nagłówki kolumn. W SQL te nagłówki stają się definicją tabel.

Przykładowa tabela klienci może wyglądać tak:

Podobnie dla produktów:

A tu zamówienia i ich pozycje:

W Excelu to wszystko byłoby jedną szeroką tabelą z masą powtórzeń. W SQL dane klienckie siedzą w jednym miejscu, dane o produktach w drugim, a zamówienia i pozycje sklejają to w spójną całość.

Jak podejrzeć taką bazę w kliencie SQL

Gdy baza jest zainstalowana, a klient (np. DBeaver) połączony, następnym krokiem jest zwykłe „rozejrzenie się po magazynie”. To bardzo podobne do otwarcia pliku Excela i rzucenia okiem na zakładki.

• Po lewej stronie zwykle widać listę baz danych, schematów i tabel.
• Po rozwinięciu schematu (np. public w PostgreSQL) zobaczysz listę tabel: klienci, produkty, zamowienia, pozycje_zamowien itd.
• Po kliknięciu tabeli najczęściej można wybrać opcję „View Data” lub podobną – to odpowiednik otwarcia arkusza z danymi.

Ten widok podglądu danych jest przydatny psychologicznie: pokazuje, że SQL to nie magia, tylko zwykłe wiersze i kolumny, tylko trzymane przez inny program niż Excel.

SELECT jako okno na dane – pierwsze zapytania

Najważniejsze słowo, które trzeba oswoić na początku, to SELECT. Można je traktować jak bardziej elastyczne „Zaznacz wszystko” w Excelu. Różnica: zaznaczasz nie myszką, tylko tekstem.

Najprostsze możliwe zapytanie:

SELECT * FROM klienci;

Instrukcja oznacza tyle, co: „Pokaż wszystkie kolumny (*) z tabeli klienci”. Gwiazdka to skrót – tak jakby powiedzieć „wszystko, co tam masz”. W kliencie SQL wynik zapytania pojawia się w dolnym panelu jako tabelka.

Podobnie dla innych tabel:

SELECT * FROM produkty;
SELECT * FROM zamowienia;
SELECT * FROM pozycje_zamowien;

To odpowiednik klikania kolejnych zakładek w Excelu. Z tą różnicą, że:

• masz pełną kontrolę, co chcesz widzieć,
• łatwo dodać warunki, sortowanie, wyliczenia.

Wybieranie konkretnych kolumn – jak ukrywanie kolumn w Excelu

Często nie potrzebujesz wszystkich kolumn. W Excelu ukrywasz zbędne kolumny albo zaznaczasz tylko kilka. W SQL robisz to od razu w zapytaniu.

Przykład dla tabeli klientów:

SELECT
    id_klienta,
    nazwa,
    miasto
FROM klienci;

Tutaj mówisz wprost: „Pokaż mi tylko te trzy kolumny.” Nic nie trzeba później ukrywać, nic czyścić, bo nadmiarowe kolumny w ogóle nie lądują w wyniku.

Można też zmienić nazwę kolumny w wyniku, tak jakbyś w Excelu nadał „etykietę” w tabeli przestawnej:

SELECT
    nazwa AS klient,
    miasto AS miejscowosc
FROM klienci;

Słówko AS działa jak „podpisz tę kolumnę inaczej w raporcie”. W samej tabeli nic się nie zmienia, to tylko etykieta w wyniku.

Dodawanie prostych wyliczeń – kolumna obliczeniowa w SQL

Wyobraź sobie, że masz tabelę pozycji zamówień i chcesz zobaczyć wartość pozycji (ilość × cena). W Excelu dodajesz nową kolumnę, wpisujesz formułę, przeciągasz w dół. W SQL nie tworzysz dodatkowej kolumny w tabeli – wyliczasz ją w locie w zapytaniu.

SELECT
    id_pozycji,
    id_zamowienia,
    id_produktu,
    ilosc,
    cena_netto,
    ilosc * cena_netto AS wartosc_pozycji
FROM pozycje_zamowien;

Taka wyliczona kolumna istnieje tylko w wyniku zapytania. Jeśli zmienią się dane źródłowe (np. ilość), wystarczy ponownie uruchomić SELECT, a wartości policzą się na nowo. To jak formuła tablicowa, tylko że nie musisz się martwić o zakresy.

Pierwsze komendy SQL – SELECT jak „zaznacz wszystko” w Excelu

Składnia SELECT krok po kroku

Na początku dobrze jest „rozebrać” SELECT na części. Typowe proste zapytanie ma taki kształt:

SELECT <co>
FROM <skad>
WHERE <warunek>
ORDER BY <sortowanie>;

Nie wszystkie części muszą się pojawiać od razu. Wersja „minimalna” ma tylko SELECT i FROM:

SELECT *
FROM produkty;

To jest dokładny odpowiednik „Zaznacz wszystko” na arkuszu z produktami. Później możesz dodawać pozostałe elementy jak klocki:

• WHERE – wybór wierszy (jak filtr),
• ORDER BY – sortowanie (jak sortowanie rosnąco/malejąco),
• funkcje agregujące (SUM, COUNT, AVG) – jak podsumowania.

Proste „zrzuty” danych – jak Ctrl+A, Ctrl+C w Excelu

Czasem celem jest po prostu zobaczyć, co siedzi w tabeli, albo wyeksportować dane do Excela. Takie „zrzuty” robi się właśnie za pomocą prostych SELECT.

Przykłady:

-- Wszystkie zamówienia
SELECT * FROM zamowienia;

-- Pierwsze 100 klientów (w niektórych systemach)
SELECT * FROM klienci
LIMIT 100;

Słówko LIMIT przydaje się przy dużych tabelach. Zamiast wczytywać milion wierszy, na start oglądasz próbkę – jakbyś ściął arkusz Excela do pierwszych kilku ekranów.

Sortowanie danych – ORDER BY jak sortowanie w tabeli

W Excelu klikasz „Sortuj od A do Z” po wybranej kolumnie. W SQL robi to ORDER BY.

SELECT
    id_klienta,
    nazwa,
    miasto
FROM klienci
ORDER BY nazwa ASC;

Parametr ASC oznacza sortowanie rosnące (A–Z, od najmniejszych do największych). Dla malejącego użyjesz DESC:

SELECT
    id_klienta,
    nazwa,
    miasto
FROM klienci
ORDER BY nazwa DESC;

Możesz też sortować po kilku kolumnach jednocześnie – najpierw po mieście, potem po nazwie klienta:

SELECT
    nazwa,
    miasto
FROM klienci
ORDER BY
    miasto ASC,
    nazwa ASC;

W Excelu też da się to zrobić, ale zwykle musisz przeklikać kilka opcji w oknie sortowania. W SQL wszystko masz zapisane w jednym krótkim poleceniu.

Proste podsumowania – SUM i COUNT zamiast SUMA i ILE.WIERSZY

Gdy w Excelu chcesz policzyć sumę kolumny, wpisujesz =SUMA(). W SQL używasz funkcji agregujących, ale stosujesz je na całej tabeli lub na filtrowanym zbiorze.

Zacznijmy od policzenia wszystkich pozycji zamówień:

SELECT COUNT(*) AS liczba_pozycji
FROM pozycje_zamowien;

To odpowiednik =ILE.WIERSZY() na całej tabeli. Z kolei suma wartości pozycji może wyglądać tak:

SELECT
    SUM(ilosc * cena_netto) AS laczna_wartosc_sprzedazy
FROM pozycje_zamowien;

Nic nie trzeba przeciągać myszką, nie trzeba pilnować, czy zakres kończy się na wierszu 1000 czy 100 000. Baza sama obejmie wszystkie pasujące wiersze.

Filtrowanie danych – WHERE jako lepszy odpowiednik FILTRUJ i AUTOFILTER

Podstawowy filtr – WHERE jak proste kryterium w Excelu

Filtry to chleb powszedni w Excelu: „pokaż klientów z Warszawy”, „pokaż zamówienia z ostatniego miesiąca”. W SQL robi to klauzula WHERE. Możesz traktować ją jak tekstową wersję panelu filtrów.

Klienci z konkretnego miasta:

SELECT
    id_klienta,
    nazwa,
    miasto
FROM klienci
WHERE miasto = 'Warszawa';

Zamówienia z wybranego dnia:

SELECT
    id_zamowienia,
    id_klienta,
    data_zamowienia
FROM zamowienia
WHERE data_zamowienia = '2024-01-15';

W porównaniu z filtrem w Excelu różnica jest taka, że wynik SELECT nie modyfikuje oryginalnej tabeli. Nic nie ukrywasz, nic nie „psujesz” – baza tylko zwraca widok spełniający podany warunek.

Filtry z porównaniami – większe, mniejsze, różne od

W Excelu ustawiasz filtr „większe niż”, „mniejsze niż” czy „nie równe”. W SQL robisz to za pomocą operatorów porównania w WHERE.

Przykład: zamówienia o wartości powyżej 1000 zł. Załóżmy, że masz w tabeli zamowienia kolumnę wartosc_netto:

SELECT
    id_zamowienia,
    id_klienta,
    data_zamowienia,
    wartosc_netto
FROM zamowienia
WHERE wartosc_netto > 1000;

Inne typowe porównania:

• < – mniejsze niż,
• <= – mniejsze lub równe,
• >= – większe lub równe,
• <> lub != – różne od.

Klienci spoza Warszawy:

SELECT
    id_klienta,
    nazwa,
    miasto
FROM klienci
WHERE miasto <> 'Warszawa';

Daty też możesz porównywać jak liczby. Zamówienia po konkretnej dacie:

SELECT
    id_zamowienia,
    id_klienta,
    data_zamowienia
FROM zamowienia
WHERE data_zamowienia >= '2024-02-01';

Łączenie warunków – AND, OR i nawiasy jak złożone filtry

W Excelu zaznaczasz kilka warunków naraz: miasto = „Warszawa” i wartość > 1000. SQL ma do tego słowa AND oraz OR. Działają dokładnie tak, jak brzmią: „i” oraz „albo”.

Klienci z Warszawy i z wysokim limitem kredytowym:

SELECT
    id_klienta,
    nazwa,
    miasto,
    limit_kredytowy
FROM klienci
WHERE miasto = 'Warszawa'
  AND limit_kredytowy >= 50000;

Z kolei, jeśli chcesz Warszawę albo Kraków, użyjesz OR:

SELECT
    id_klienta,
    nazwa,
    miasto
FROM klienci
WHERE miasto = 'Warszawa'
   OR miasto = 'Kraków';

Przy bardziej skomplikowanych kryteriach ratują cię nawiasy – tak jak w formułach excellowych. Chcesz klientów z Warszawy z dużym limitem lub klientów z Krakowa (niezależnie od limitu)?

SELECT
    id_klienta,
    nazwa,
    miasto,
    limit_kredytowy
FROM klienci
WHERE (miasto = 'Warszawa' AND limit_kredytowy >= 50000)
   OR miasto = 'Kraków';

Bez nawiasów łatwo dostać inny wynik, niż podpowiada zdrowy rozsądek. Dobrą praktyką jest dodawanie nawiasów zawsze, gdy mieszasz AND i OR – wtedy czytasz zapytanie jak zdanie po polsku.

Wielowartościowe filtry – IN zamiast wielu „albo”

Czasem lista wartości rośnie: nie dwa miasta, ale dziesięć; nie jeden status, ale cały zestaw. W Excelu to kilka kliknięć w panelu filtra. W SQL użyjesz IN.

Klienci z wybranych miast:

SELECT
    id_klienta,
    nazwa,
    miasto
FROM klienci
WHERE miasto IN ('Warszawa', 'Kraków', 'Gdańsk');

To odpowiednik:

WHERE miasto = 'Warszawa'
   OR miasto = 'Kraków'
   OR miasto = 'Gdańsk'

– tylko krótszy i czytelniejszy.

Jest też odwrotność: NOT IN. Produkty, które nie są w danej kategorii:

SELECT
    id_produktu,
    nazwa,
    kategoria
FROM produkty
WHERE kategoria NOT IN ('Usługa', 'Abonament');

Zakresy wartości – BETWEEN jak filtr od–do

W raportach biznesowych królują zakresy: daty od–do, wartości od–do, numery dokumentów w danym przedziale. W SQL pomaga BETWEEN.

Zamówienia z lutego 2024:

SELECT
    id_zamowienia,
    id_klienta,
    data_zamowienia
FROM zamowienia
WHERE data_zamowienia BETWEEN '2024-02-01' AND '2024-02-29';

BETWEEN jest włącznie, czyli obejmuje oba końce zakresu. Dla liczb działa tak samo:

SELECT
    id_produktu,
    nazwa,
    cena_netto
FROM produkty
WHERE cena_netto BETWEEN 50 AND 200;

Jeśli wolisz pełną kontrolę, możesz zawsze zapisać to klasycznie:

WHERE cena_netto >= 50
  AND cena_netto <= 200

Filtrowanie tekstu – LIKE jak wyszukiwanie z gwiazdką

W Excelu często używasz wyszukiwania z symbolami wieloznacznymi: „zaczyna się na”, „zawiera”, „kończy się na”. W SQL służy do tego LIKE i znak % (dowolny ciąg znaków).

Klienci, których nazwa zaczyna się na „ABC”:

SELECT
    id_klienta,
    nazwa
FROM klienci
WHERE nazwa LIKE 'ABC%';

Nazwa zawiera słowo „Sklep”:

SELECT
    id_klienta,
    nazwa
FROM klienci
WHERE nazwa LIKE '%Sklep%';

A jeśli interesuje cię końcówka (np. domena e-mail):

SELECT
    id_klienta,
    email
FROM klienci
WHERE email LIKE '%@gmail.com';

Istnieje też znak _ (podkreślnik) – odpowiada dokładnie jednemu znakowi. Przydaje się rzadziej, ale możesz dzięki niemu szukać np. kodów o stałym wzorcu.

Filtrowanie pustych wartości – IS NULL i IS NOT NULL

Puste komórki w Excelu to często źródło nieporozumień. W SQL „brak wartości” ma specjalne oznaczenie: NULL. Co ważne, nie porównujesz go jako = NULL, tylko używasz IS NULL.

Klienci bez przypisanego numeru NIP:

SELECT
    id_klienta,
    nazwa,
    nip
FROM klienci
WHERE nip IS NULL;

A teraz odwrotnie – lista klientów z uzupełnionym NIP-em:

SELECT
    id_klienta,
    nazwa,
    nip
FROM klienci
WHERE nip IS NOT NULL;

W praktyce taki filtr jest nieoceniony przy sprzątaniu danych: od razu widzisz, gdzie brakuje istotnych pól (np. kodu pocztowego, adresu e-mail, kategorii produktu).

Łączenie filtrowania z agregacją – raporty „na raz”

Kiedy połączysz WHERE z funkcjami agregującymi, zaczyna się robić ciekawie. To jakbyś na jednym widoku połączył filtrowanie, autosumę i kilka formuł pomocniczych.

Przykład: łączna wartość sprzedaży w 2023 roku:

SELECT
    SUM(ilosc * cena_netto) AS wartosc_2023
FROM pozycje_zamowien
WHERE data_zamowienia BETWEEN '2023-01-01' AND '2023-12-31';

Albo liczba zamówień klienta z konkretnym identyfikatorem:

SELECT
    COUNT(*) AS liczba_zamowien_klienta
FROM zamowienia
WHERE id_klienta = 123;

W Excelu musiałbyś najpierw przefiltrować wiersze, potem dodać formuły. W SQL logika jest zamknięta w jednym zdaniu, które można łatwo skopiować, zmodyfikować i uruchomić ponownie.

Filtrowanie po wyrażeniach – warunek na wyliczeniu

Nic nie stoi na przeszkodzie, żeby w WHERE użyć tej samej logiki, którą wykorzystujesz w kolumnach obliczeniowych. To trochę jak filtr na kolumnie z formułą w Excelu – tyle że tu obliczenie nie musi być fizycznie zapisane.

Zamówienia, których łączna wartość pozycji przekracza 5000 zł. Załóżmy, że w tabeli pozycje_zamowien wartość pozycji liczysz jako ilosc * cena_netto:

SELECT
    id_zamowienia,
    SUM(ilosc * cena_netto) AS wartosc_zamowienia
FROM pozycje_zamowien
GROUP BY id_zamowienia
HAVING SUM(ilosc * cena_netto) > 5000;

Pojawia się tu nowe słowo HAVING – pełni rolę filtra, ale działa na poziomie pogrupowanych wyników (po GROUP BY), nie na pojedynczych wierszach. Analogią jest filtr na wierszach tabeli przestawnej: nie widzisz poszczególnych pozycji, tylko już podsumowane zamówienia.

Praktyczny mini-scenariusz: szybka lista do windykacji

Wyobraź sobie, że księgowość prosi: „Przygotuj listę klientów, którzy mają przeterminowane faktury powyżej 2000 zł i nie podali adresu e-mail.” W Excelu oznaczałoby to kilka kroków: filtry po dacie, po kwocie, dodatkowa kolumna z formułą, sprawdzanie pustych maili.

W SQL możesz zbudować to jako jedno zapytanie. Załóżmy, że masz tabelę faktury z kolumnami id_klienta, saldo, termin_platnosci i tabelę klienci z kolumną email:

SELECT
    k.id_klienta,
    k.nazwa,
    k.miasto,
    k.email,
    SUM(f.saldo) AS przeterminowane_saldo
FROM klienci k
JOIN faktury f ON f.id_klienta = k.id_klienta
WHERE f.termin_platnosci < CURRENT_DATE
  AND f.saldo > 0
  AND k.email IS NULL
GROUP BY
    k.id_klienta,
    k.nazwa,
    k.miasto,
    k.email
HAVING SUM(f.saldo) > 2000
ORDER BY przeterminowane_saldo DESC;

Pierwsze spotkanie z takim zapytaniem może wyglądać groźnie, ale jeśli rozbijesz je na znajome już elementy – WHERE, agregacja, filtr na sumie – wychodzi z tego bardzo przewidywalna układanka. A lista do windykacji generuje się jednym kliknięciem „Run”.

Najczęściej zadawane pytania (FAQ)

Skąd wiedzieć, że czas przejść z Excela na SQL?

Najprostszy sygnał: Excel zaczyna przymulać. Plik waży dziesiątki megabajtów, otwiera się kilka minut, filtr zmienia się wieczność, a zapis pliku potrafi zawiesić komputer. Do tego rośnie liczba zakładek, formuły są coraz bardziej skomplikowane i nikt już nie wie, która wersja raportu jest „tą właściwą”.

Drugi moment graniczny to praca zespołowa. Gdy kilka osób równolegle przerabia te same dane, krążą maile z plikami „v4_ostateczna_poprawiona”, a różnice między wersjami łatwo przeoczyć, baza danych i SQL zaczynają mieć po prostu więcej sensu.

Czy do nauki SQL muszę umieć programować?

Nie. SQL to język zapytań, a nie klasyczne programowanie jak Python czy Java. Bardziej mówisz bazie: „Pokaż mi wszystkie wiersze z tej tabeli, przefiltruj je i podlicz sprzedaż”, niż budujesz całe aplikacje. Dla osoby, która ogarnia formuły i tabele przestawne w Excelu, sposób myślenia w SQL jest bardzo naturalny.

Na starcie wystarczy znajomość podstaw pracy z danymi: filtrowanie, sortowanie, proste obliczenia. Jeśli radzisz sobie z SUMA, JEŻELI czy WYSZUKAJ.PIONOWO, to w SQL przeskok jest raczej jak przeprowadzka do większego mieszkania niż jak skok na zupełnie inną planetę.

Od czego zacząć naukę SQL, jeśli do tej pory pracowałem tylko w Excelu?

Dobrze zacząć od prostego celu: na przykład „przepisać” istniejący raport z Excela na zapytanie SQL. Wybierz jedną tabelę (arkusz), przenieś dane do bazy i spróbuj odtworzyć znane operacje: filtrowanie, grupowanie, sumy, proste warunki.

Technicznie potrzebujesz trzech rzeczy: darmowej bazy danych (np. SQLite, PostgreSQL, MySQL lub SQL Server Express), narzędzia do pisania zapytań (zwykle instaluje się razem z bazą) i niewielkiego zestawu danych – choćby fragmentu Twojego excela wyeksportowanego do CSV. Uczysz się wtedy na czymś, co naprawdę znasz, a nie na sztucznych przykładach.

Jaka baza danych jest najlepsza do nauki SQL dla początkujących?

Dobry wybór to taka baza, którą realnie możesz potem wykorzystać w pracy albo projektach. Kilka typowych scenariuszy:

• SQLite – świetna do nauki podstaw, instalacja jest banalna, wszystko mieści się w jednym pliku.
• PostgreSQL – bardzo uniwersalna i popularna w analizie danych, dobra, jeśli myślisz o bardziej zaawansowanych zastosowaniach.
• MySQL / MariaDB – jeśli interesują Cię też projekty webowe lub pracujesz blisko działu IT.
• SQL Server Express – naturalny wybór, gdy w firmie króluje Microsoft (Excel, Power BI, SharePoint).

Jeżeli w Twojej pracy działa już jakiś konkretny system bazodanowy, sensownie jest zacząć właśnie od niego – szybciej zobaczysz praktyczny efekt.

Czym konkretnie różni się tabela w Excelu od tabeli w SQL?

Z wierzchu wyglądają podobnie: wiersze, kolumny, nagłówki. Różnica zaczyna się pod spodem. W Excelu w jednej kolumnie możesz mieć liczby, teksty, daty i puste komórki wymieszane „jak leci”. W SQL każda kolumna ma jasno określony typ: liczba, tekst, data itd. i nie da się tam „wcisnąć” danych z innej bajki.

Do tego w bazie możesz wymusić pewne zasady: np. że w kolumnie z numerem klienta nie ma pustych pól, że identyfikator jest unikalny albo że data musi być prawdziwą datą. Dzięki temu dane są zdecydowanie bardziej spójne, a Ty mniej czasu spędzasz na polowaniu na błędy w stylu „b.d.” zamiast daty.

Czy po przejściu na SQL Excel przestanie mi być potrzebny?

Nie, Excel po prostu zmienia rolę. Z narzędzia „do wszystkiego” staje się narzędziem końcowym: do prezentacji, szybkich analiz, wykresów i pracy „na wierzchu” danych. SQL przejmuje ciężką robotę: przechowywanie, łączenie, czyszczenie i wstępne przeliczanie dużych zbiorów.

W praktyce wygląda to tak: dane siedzą w bazie, a do Excela dociągasz tylko to, co potrzebne do konkretnego raportu. Zamiast pięciu prawie identycznych plików z kopiami tych samych tabel masz jedno źródło prawdy w SQL i różne widoki lub zapytania, które karmią raporty w Excelu lub BI.

Jak przenieść istniejący raport z Excela do SQL krok po kroku?

Najprostsza ścieżka to podejść do tego etapami. Najpierw zidentyfikuj główne arkusze z danymi (niekoniecznie wszystkie pomocnicze zakładki) i wyeksportuj je do plików CSV. Następnie załaduj te pliki jako tabele do wybranej bazy danych – większość narzędzi ma kreatory „import z CSV”.

Kolejny krok to odtworzenie logiki raportu w SQL: filtry, grupowania, sumy, proste warunki. Każdą większą formułę z Excela potraktuj jak klocki, które składasz z funkcji SQL (np. SUM, COUNT, CASE). Na końcu możesz wystawić z tego widok lub gotowe zapytanie, z którego Excel pobierze już przetworzone dane – raport pozostaje znajomy, ale silnik danych jest o poziom wyżej.

Kluczowe Wnioski

• Excel świetnie sprawdza się przy mniejszych, jednorazowych lub prostszych analizach, ale przy rozrastających się raportach (wiele arkuszy, skomplikowane formuły, tysiące wierszy) zaczyna się dławić i staje się zawodnym „magazynem wszystkiego”.
• SQL przejmuje rolę stabilnego kręgosłupa dla danych: trzyma duże, wspólne zbiory w jednym miejscu, a Excel zmienia się w narzędzie końcowe – do raportów, wykresów i szybkiego „podłubania” w danych, a nie do ich przechowywania.
• Do SQL-a naturalnie dochodzą specjaliści z bardzo różnych działów (analitycy, HR, finanse, marketing), gdy dane wykraczają poza jeden plik i trzeba je łączyć z wielu systemów oraz udostępniać zespołowi bez nadpisywania sobie pracy.
• SQL jest mentalnie bliżej Excela niż klasycznego programowania: zamiast pisać aplikacje, formułujesz zapytania typu „wybierz, przefiltruj, zsumuj”, więc komuś obytemu z filtrami, tabelami przestawnymi i prostymi formułami łatwiej się w nim odnaleźć.
• Bazy danych dają to, czego brakuje Excelowi przy dużej skali: wydajność (miliony wierszy liczone w sekundy), kontrolę dostępu, kopie zapasowe, logi zmian i jedno spójne źródło prawdy, z którego każdy dział może czerpać swoje widoki.
• Struktura danych w SQL jest znacznie bardziej uporządkowana: kolumny mają określone typy, obowiązkowość, unikalność, dzięki czemu nie ma „sałatki” z dat, tekstów i pustych komórek, jak często bywa w rozrośniętych plikach Excela.