Adatbázis és DBMS: ki miért felel

1. fejezet — „Az archívum térképe”

A „Kotomarket” pillanatképe már nem egy holt szektorból érkező jel — ott pihen a Vault-9 karanténrekeszében, és a dump utolsó sora alatt ugyanaz az aláírás áll: „K.”. Reggel friss bejegyzés villan fel a holopaneleden: „Hozzáférés: az archívum jegyzéke. Kiállította: az S.Q.L. modul.” A raktár ajtaja oldalra siklik; mögötte borostyánszínű fényben egyenletesen zúgnak a szerverállványok.

QUERY: Mielőtt más emlékezetét olvasnád, értsd meg, hogyan épül fel. Kezdjük a lényeggel: mi itt a raktár, és ki az őrző.

Adatbázis és DBMS

Az adatbázis (DB) egy rendezett tároló. A „Kotomarket” pillanatképében vásárlók, termékek, rendelések és események pihennek: nem fájlokba szórva, hanem áttekinthető szerkezetben — ezért olvashatók még százhatvan év múltán is.

Maga a tároló azonban nem válaszol a kérdésekre. Kell egy program, amely táblákat tud létrehozni, új rendeléseket rögzít, adatokat olvas, és vigyáz arra, hogy a kapcsolatok el ne törjenek. Ez a DBMS (adatbázis-kezelő rendszer). Példák: PostgreSQL, MySQL, ClickHouse. A mi pillanatképünk egy PostgreSQL-adatbázis, és ugyanazon az SQL-en beszél, mint a bolt életében.

Megírod a lekérdezést SQL-ben → elküldöd a DBMS-nek → a DBMS előveszi a kért adatokat, és visszaadja az eredményt. Az Excel jó egy személyes táblázathoz, de nem egy bolthoz, ahol több ezer felhasználó nézegeti egyszerre a termékeket, ad le rendeléseket, és hagy eseményeket a rendszerben.

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.

Mit tud a DBMS, amit a „csak fájlok” nem

Úgy tűnhet, a bolt DBMS nélkül is elélne: a rendeléseket CSV-be vagy Excelbe írná. Egy személyes jegyzetfüzet léptékében pontosan így is tesznek — egészen addig, amíg fel nem bukkannak azok a feladatok, amelyek megoldására a DBMS-t egyáltalán kitalálták.

• Konkurens hozzáférés. Az élő „Kotomarket”-ben a vásárlók egyszerre adtak le rendeléseket. Két folyamat, amely ugyanabba a fájlba ír, felülírja egymás módosításait; a DBMS a változtatásokat tranzakciókként hajtja végre, és maga keríti el a párhuzamos műveleteket. A PostgreSQL ezt az MVCC mechanizmuson keresztül teszi: az olvasók nem blokkolják az írókat, és fordítva sem.
• Helyreállítás összeomlás után. Az áram megrebben az írás közepén — a fájl megsérül, és nem tudni, a rendelés melyik fele került még a lemezre. A DBMS először a naplóban rögzíti a változtatást (a PostgreSQL-ben ez a WAL, a write-ahead log), és összeomlás után lejátssza azt: a rendelés vagy teljes egészében rögzül, vagy egyáltalán nem.
• Hozzáférési jogok. Egy fájl vagy teljesen nyitva van, vagy sehogy. A DBMS-ben a jogok finomszemcsések — akár egyetlen tábla szintjéig:

-- Az elemzőnek csak a rendelések olvasása, módosítási jog nélkül
GRANT SELECT ON orders TO analyst;

• Integritás. A DBMS nem fogad el olyan rendelést, amelyben az ár szöveg, vagy amely egy nem létező vásárlóra hivatkozik: az oszloptípusokat és a megszorításokat minden íráskor ellenőrzi. A fájlt nem érdekli, mi van benne.
• Deklaratív kérdések. „Mutasd a 5000-nél drágább rendeléseket” — egyetlen sor SQL. Fájllal ugyanezt a munkát egy program végzi, amelyet valakinek meg kell írnia, és nem hibázhat.