Database og DBMS: hvem gør hvad

Kapitel 1 — »Arkivets kort«

Kotomarket-snapshottet er ikke længere et signal fra en død sektor — det ligger i en karantænesektion om bord på Vault-9, og under den sidste linje i dumpet står stadig den samme underskrift: »K.«. I morges blinker en ny post frem på dit holopanel: »Adgang givet: arkivets indeks. Udstedt af: modul S.Q.L.« Hvælvingsdøren glider til side; bag den summer serverrækkerne roligt i et ravgult skær.

QUERY: Før du læser en andens hukommelse, så forstå, hvordan den er bygget op. Lad os begynde med det vigtigste: hvad her er lageret, og hvem der er holderen.

Database og DBMS

En database (DB) er et organiseret lager. I Kotomarket-snapshottet ligger kunder, varer, ordrer og hændelser: ikke spredt ud i filer, men i en overskuelig struktur — og derfor kan de stadig læses selv hundredeseksti år senere.

Men selve lageret svarer ikke på spørgsmål. Der skal et program til, som kan oprette tabeller, registrere nye ordrer, læse data og sørge for, at forbindelserne ikke knækker. Det er en DBMS (databasestyringssystem). Eksempler: PostgreSQL, MySQL, ClickHouse. Vores snapshot er en PostgreSQL-database, og den taler stadig det samme SQL som dengang, butikken levede.

Du skriver en forespørgsel i SQL → sender den til DBMS'en → DBMS'en henter de data, du bad om, og returnerer resultatet. Excel er fint til et personligt regneark, men ikke til en butik, hvor tusindvis af brugere på én gang kigger på varer, afgiver ordrer og efterlader hændelser i systemet.

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.

Hvad en DBMS kan, som »bare filer« ikke kan

Det kunne se ud, som om butikken godt kunne klare sig uden en DBMS: bare skrive ordrer i en CSV- eller Excel-fil. På et personligt notesblok-niveau gør man netop det — lige indtil de opgaver dukker op, som en DBMS i det hele taget blev opfundet for at løse.

• Samtidig adgang. I det levende Kotomarket afgav kunderne ordrer på samme tid. To processer, der skriver til den samme fil, overskriver hinandens ændringer; en DBMS udfører ændringer som transaktioner og holder selv styr på de parallelle operationer. PostgreSQL gør det via mekanismen MVCC: læsere blokerer ikke skrivere, og omvendt.
• Genoprettelse efter nedbrud. Strømmen blinker midt i en skrivning — filen bliver beskadiget, og man ved ikke, hvilken halvdel af ordren der nåede at blive gemt. En DBMS registrerer først ændringen i en log (i PostgreSQL — WAL, write-ahead log) og spiller den til ende efter et nedbrud: ordren er enten skrevet helt eller slet ikke.
• Adgangsrettigheder. En fil er enten åben helt eller slet ikke. I en DBMS er rettighederne granulære — helt ned til den enkelte tabel:

-- Analytikeren — kun læseadgang til ordrer, uden ret til at ændre dem
GRANT SELECT ON orders TO analyst;

• Integritet. En DBMS tager ikke imod en ordre med en pris-tekststreng eller med en henvisning til en kunde, der ikke findes: kolonnernes typer og begrænsninger tjekkes ved hver skrivning. En fil er ligeglad med, hvad der ligger i den.
• Deklarative spørgsmål. »Vis ordrer dyrere end 5000« — én linje SQL. Med en fil udfører et program det samme arbejde, et program, som nogen skal skrive uden at lave fejl.