Baza danych i DBMS: kto za co odpowiada

Rozdział 1 — „Mapa archiwum”

Migawka „Kotomarketu” nie jest już sygnałem z martwego sektora — leży w komorze kwarantanny Vault-9, a pod ostatnią linijką jej zrzutu wciąż widnieje ten sam podpis: „K.”. Rano na twoim holopanelu zapala się nowy wpis: „Dostęp przyznany: inwentarz archiwum. Wydał: moduł S.Q.L.” Drzwi magazynu odsuwają się na bok; za nimi, w bursztynowym świetle, równo szumią serwerowe szafy.

QUERY: Zanim zaczniesz czytać cudzą pamięć, zrozum, jak jest zbudowana. Zacznijmy od najważniejszego: co jest magazynem, a kto strażnikiem.

Baza danych i DBMS

Baza danych to uporządkowany magazyn. W migawce „Kotomarketu” są kupujący, towary, zamówienia i zdarzenia: nie luzem w plikach, lecz w czytelnej strukturze — dlatego można je odczytać nawet po stu sześćdziesięciu latach.

Sam magazyn nie odpowiada jednak na pytania. Potrzebny jest program, który potrafi tworzyć tabele, zapisywać nowe zamówienia, czytać dane i pilnować, żeby powiązania się nie zerwały. To DBMS (system zarządzania bazami danych). Przykłady: PostgreSQL, MySQL, ClickHouse. Nasza migawka to baza PostgreSQL i używa tego samego SQL-a, którym sklep posługiwał się za życia.

Piszesz zapytanie w SQL → wysyłasz je do DBMS → DBMS wydobywa potrzebne dane i zwraca wynik. Excel sprawdza się jako osobisty arkusz, ale nie jako silnik sklepu, w którym tysiące użytkowników jednocześnie oglądają towary, składają zamówienia i zostawiają po sobie zdarzenia w systemie.

Database and DBMS

A database is an organized store. The Kotomarket snapshot holds buyers, products, orders, and events — not scattered across files, but in a clear structure. That’s exactly why it can still be read a hundred and sixty years later.

But the store itself doesn’t answer questions. You need a program that can create tables, record new orders, read data, and make sure the links never break. That’s a DBMS (database management system). Examples: PostgreSQL, MySQL, ClickHouse. Our snapshot is a PostgreSQL database, and it still speaks the same SQL it did when the shop was alive.

You write a query in SQL → send it to the DBMS → the DBMS fetches the data you asked for and returns the result. Excel is fine for a personal spreadsheet, but not for a shop where thousands of users browse products, place orders, and leave events in the system all at once.

Co DBMS potrafi, czego nie potrafią „zwykłe pliki”

Może się wydawać, że sklep mógłby działać bez DBMS: zapisywać zamówienia do CSV albo Excela. W skali osobistego notesu to działa — dopóki nie pojawią się zadania, dla których DBMS-y w ogóle powstały.

• Dostęp współbieżny. W żywym „Kotomarkecie” kupujący składali zamówienia jednocześnie. Dwa procesy zapisujące do jednego pliku potrafią nadpisać sobie nawzajem zmiany; DBMS wykonuje zmiany jako transakcje i sam porządkuje operacje równoległe. PostgreSQL robi to za pomocą mechanizmu MVCC: czytający nie blokują piszących i odwrotnie.
• Odzyskiwanie po awarii. Zasilanie mignęło w połowie zapisu — plik się uszkodził i nie wiadomo, która część zamówienia zdążyła się zapisać. DBMS najpierw utrwala zmianę w dzienniku (w PostgreSQL — WAL, write-ahead log), a po awarii ją odtwarza: zamówienie jest zapisane w całości albo nie ma go wcale.
• Prawa dostępu. Plik jest dostępny w całości albo wcale. W DBMS prawa są szczegółowe — aż do pojedynczej tabeli:

-- Analitykowi — tylko odczyt zamówień, bez prawa ich zmieniać
GRANT SELECT ON orders TO analyst;

• Spójność. DBMS nie przyjmie zamówienia z ceną zapisaną jako tekst ani z odwołaniem do nieistniejącego kupującego: typy kolumn i ograniczenia są sprawdzane przy każdym zapisie. Plikowi jest obojętne, co w nim leży.
• Deklaratywne pytania. „Pokaż zamówienia droższe niż 5000” — jedna linijka SQL. Przy plikach tę samą pracę musiałby wykonać program, który ktoś musi napisać i którego ktoś musi nie zepsuć.