SQL czy NoSQL — kiedy co ma sens

Pytanie wraca w każdym projekcie i zwykle pada za wcześnie. Zanim się na coś zdecydujesz, warto wiedzieć, czym te bazy naprawdę się różnią — bo nie chodzi o to, która jest nowocześniejsza.

Relacyjne: tabele i twarde reguły

MySQL, PostgreSQL, MariaDB. Dane siedzą w tabelach o z góry ustalonych kolumnach, a baza sama pilnuje, żeby się zgadzały: zamówienie nie może wskazywać na nieistniejącego klienta, kwota musi być liczbą, adres e-mail musi być unikalny.

Największą zaletą są transakcje. Przelew to zdjęcie kwoty z jednego konta i dopisanie do drugiego. Baza gwarantuje, że albo wykonają się obie operacje, albo żadna — nawet jeśli w połowie zabraknie prądu. Tam, gdzie w grę wchodzą pieniądze albo stany magazynowe, to argument, który kończy dyskusję.

NoSQL: dokumenty i swoboda

MongoDB, Redis, Elasticsearch. Zamiast tabel — dokumenty, które mogą się między sobą różnić. Jeden produkt ma rozmiar i kolor, drugi moc i napięcie, i żadnego z nich nie trzeba wcześniej deklarować.

Drugą zaletą jest łatwiejsze rozłożenie danych na wiele serwerów. Baza relacyjna też to potrafi, ale wymaga to znacznie więcej pracy.

Wybór w praktyce

Trzeci wariant, o którym się zapomina

Nowoczesne bazy relacyjne mają typ kolumny JSON. Można w jednej tabeli trzymać sztywną część danych — identyfikator, cenę, stan magazynowy — a zmienne cechy produktu wrzucić do kolumny JSON i przeszukiwać ją zapytaniem.

W praktyce to najczęściej najrozsądniejszy wybór: dostajesz swobodę tam, gdzie jest potrzebna, i twarde reguły tam, gdzie chodzi o pieniądze.

Zacznij od bazy relacyjnej. Dołóż coś innego dopiero wtedy, gdy poczujesz konkretny ból, a nie zanim.

Warto też pamiętać, że w typowym projekcie te bazy nie konkurują — MySQL trzyma zamówienia, Redis sesje, a Elasticsearch obsługuje wyszukiwarkę. Każde narzędzie robi to, w czym jest najlepsze.