Relacyjne i nierelacyjne bazy danych (SQL vs NoSQL) – czym się różnią i którą wybrać

Prawie każda aplikacja gdzieś zapisuje dane: użytkowników, zamówienia, wiadomości. Od tego, jak je przechowasz, zależy, jak wygodnie będziesz je później odczytywać, zmieniać i łączyć. Poniżej wyjaśniamy, czym jest baza danych, jak różnią się relacyjne od nierelacyjnych i którą wybrać. Przykłady SQL uruchomiliśmy w SQLite 3.51, a przykłady dla baz nierelacyjnych to zwykły zapis danych, którego nie uruchamialiśmy.

Czym jest baza danych?

Baza danych to uporządkowany zbiór danych razem z programem (systemem zarządzania bazą danych, w skrócie DBMS), który pozwala je bezpiecznie zapisywać, wyszukiwać i zmieniać. Sam plik z danymi to jeszcze nie baza. Baza dodaje m.in. szybkie wyszukiwanie, kontrolę dostępu, pilnowanie spójności i możliwość pracy wielu użytkowników naraz.

Czym jest relacyjna baza danych?

W bazie relacyjnej dane leżą w tabelach złożonych z wierszy i kolumn. Każda tabela ma z góry zadaną strukturę (schemat): wiadomo, jakie są kolumny i jakiego typu. Wiersze identyfikuje klucz główny, a tabele łączą się ze sobą kluczami obcymi, czyli relacjami. Zapytania pisze się w języku SQL.

CREATE TABLE customers (
    id INTEGER PRIMARY KEY,
    name TEXT NOT NULL,
    city TEXT
);

CREATE TABLE orders (
    id INTEGER PRIMARY KEY,
    customer_id INTEGER NOT NULL REFERENCES customers(id),
    total REAL NOT NULL
);

SELECT c.name, COUNT(o.id) AS orders, SUM(o.total) AS total
FROM customers c
JOIN orders o ON o.customer_id = c.id
GROUP BY c.id;

W naszym teście wynik to Anna | 2 | 155.5 i Piotr | 1 | 80.0. Szczegółowo o tym, jak działają złączenia, piszemy w artykule o relacjach i JOIN-ach w SQL.

Co daje schemat i klucze obce?

Baza pilnuje spójności za Ciebie. Gdy włączona jest kontrola kluczy obcych, próba dodania zamówienia dla nieistniejącego klienta kończy się błędem (FOREIGN KEY constraint failed), więc w bazie nie powstają „osierocone” dane.

Co to są transakcje i ACID?

Transakcja to grupa operacji wykonanych „wszystko albo nic”. Relacyjne bazy zwykle gwarantują cechy ACID: atomowość, spójność, izolację i trwałość. W teście rozpoczęliśmy transakcję, zmieniliśmy kwotę zamówienia na 0, a po ROLLBACK w bazie nadal była oryginalna wartość 120.5. To ważne wszędzie tam, gdzie nie możesz zgubić ani zdublować danych, np. przy płatnościach.

Jakie są popularne relacyjne bazy danych?

Najczęściej spotkasz PostgreSQL, MySQL i SQLite. Ten ostatni to baza w pojedynczym pliku, wygodna do nauki i małych aplikacji. Komercyjnie używa się też m.in. Oracle i Microsoft SQL Server.

Czym jest nierelacyjna baza danych (NoSQL)?

NoSQL nie jest jedną technologią. To parasol dla baz, które nie opierają się na modelu tabel z relacjami i często zapewniają większą swobodę kształtu danych. Nazwę czyta się zwykle jako „not only SQL”. Dane przechowuje się w innej formie, zależnie od rodzaju bazy.

Jakie są rodzaje nierelacyjnych baz danych?

Jak wygląda dokument w bazie dokumentowej?

Zamiast kilku powiązanych tabel masz jeden dokument z zagnieżdżonymi danymi:

{
  "name": "Anna",
  "city": "Warszawa",
  "orders": [
    { "total": 120.5 },
    { "total": 35 }
  ]
}

Wszystko o kliencie jest w jednym miejscu, więc odczyt jest prosty. Kosztem jest powielanie danych: jeśli ta sama informacja (np. adres) siedzi w wielu dokumentach, zmiana wymaga poprawienia każdego z nich.

Do czego służy baza klucz-wartość?

Najprostszy model: pytasz o klucz i dostajesz wartość. Dlatego takie bazy są bardzo szybkie i świetnie nadają się na cache oraz sesje. O tym, jak działa najpopularniejsza z nich, piszemy w artykule o Redisie. Z kolei bazy wektorowe, na których buduje się wyszukiwanie semantyczne i RAG, opisujemy w tekście o bazach wektorowych w Pythonie.

Czym różni się relacyjna baza danych od nierelacyjnej?

Zwróć uwagę na słowo „zwykle” w wielu wierszach. Granica się zaciera: relacyjne bazy potrafią przechowywać JSON, a część baz nierelacyjnych oferuje transakcje. W SQLite wyciągnęliśmy wartość z dokumentu JSON funkcją json_extract, a w PostgreSQL służy do tego typ jsonb (tego nie uruchamialiśmy).

Kiedy wybrać relacyjną, a kiedy nierelacyjną bazę danych?

Poniższa ściąga to punkt wyjścia, nie przepis:

Zaczynając nowy projekt, najbezpieczniej wybrać relacyjną bazę. Nierelacyjną dokładasz, gdy masz konkretny problem, który ona rozwiązuje. W wielu aplikacjach używa się obu naraz: relacyjna baza trzyma dane główne, a Redis przyspiesza odczyty.

Czy nierelacyjne bazy są szybsze od relacyjnych?

Nie ma jednej odpowiedzi. Szybkość zależy od tego, jakie zapytania zadajesz. Baza klucz-wartość jest bardzo szybka, gdy pytasz o konkretny klucz, ale słabo nadaje się do skomplikowanych zestawień, w których relacyjna baza z indeksami radzi sobie dobrze. Wybór bazy „bo jest szybsza” bez zmierzenia własnego przypadku to jedna z częstszych pomyłek przy projektowaniu.

Czy trzeba znać SQL, żeby pracować z bazami danych?

Tak, to najbezpieczniejsza inwestycja na start. SQL jest wspólnym językiem relacyjnych baz, a wiedza o tabelach, kluczach i złączeniach przydaje się też przy ORM-ach i frameworkach. Jeśli chcesz sprawdzić się pod kątem rozmów kwalifikacyjnych, zobacz pytania rekrutacyjne z baz danych i SQL. Pracy z bazami z poziomu kodu uczymy m.in. w ścieżce Python, w module o zaawansowanych bazach danych z ORM-em.

Uwaga mentora: na start nowego projektu wybieraj relacyjną bazę, np. PostgreSQL, chyba że masz konkretny powód, by tego nie robić. Relacyjna baza wybacza zmiany pomysłu na aplikację, bo dane są uporządkowane, a zapytania możesz układać na nowo. Do nierelacyjnej sięgaj wtedy, gdy wiesz, jaki problem ona rozwiązuje: cache, ogromny wolumen zapisów albo dane bez stałego kształtu.