Databas och DBMS: vem ansvarar för vad

Kapitel 1 — «Arkivets karta»

Ögonblicksbilden av «Kotomarket» är inte längre en signal från en död sektor — den ligger i en karantänbås ombord på «Valv-9», och under sista raden i dess dump står fortfarande samma signatur: «K.». I morse blinkar en ny post till på din holopanel: «Behörighet beviljad: arkivförteckningen. Utfärdad av: modul S.Q.L.» Valvdörren glider åt sidan; bakom den brummar serverrack jämnt i ett bärnstensfärgat sken.

QUERY: Innan du läser någon annans minne, förstå hur det är byggt. Vi börjar med grunderna: vad som är förrådet här, och vem som är förvaltaren.

Databas och DBMS

En databas är ett organiserat förråd. Ögonblicksbilden av «Kotomarket» rymmer köpare, varor, ordrar och händelser: inte utspridda i filer, utan i en begriplig struktur — och just därför går de att läsa även hundrasextio år senare.

Men själva förrådet svarar inte på frågor. Det krävs ett program som kan skapa tabeller, skriva in nya ordrar, läsa data och se till att kopplingarna aldrig brister. Det är ett DBMS (databashanteringssystem). Exempel: PostgreSQL, MySQL, ClickHouse. Vår ögonblicksbild är en PostgreSQL-databas, och den talar fortfarande samma SQL som när butiken levde.

Du skriver en fråga i SQL → skickar den till DBMS:et → DBMS:et hämtar de data du bad om och returnerar resultatet. Excel duger för ett personligt kalkylark, men inte för en butik där tusentals användare samtidigt bläddrar bland varor, lägger ordrar och lämnar 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.

Vad ett DBMS kan som «bara filer» inte kan

Det kan kännas som att butiken skulle kunna klara sig utan DBMS: bara skriva ordrar till en CSV eller Excel. På ett personligt anteckningsblocks skala gör man precis så — tills de uppgifter dyker upp som DBMS:et över huvud taget uppfanns för att lösa.

• Samtidig åtkomst. I det levande «Kotomarket» lade köpare ordrar samtidigt. Två processer som skriver till samma fil skriver över varandras ändringar; ett DBMS kör ändringar som transaktioner och reder själv ut de parallella operationerna. PostgreSQL gör detta via MVCC: läsare blockerar inte skrivare, och tvärtom.
• Återhämtning efter krasch. Strömmen flimrar mitt i en skrivning — filen blir korrupt, och ingen vet vilken halva av ordern som hann sparas. Ett DBMS registrerar först ändringen i en logg (i PostgreSQL — WAL, write-ahead log) och spelar upp den igen efter en krasch: ordern skrivs antingen i sin helhet eller inte alls.
• Behörigheter. En fil är öppen antingen helt eller inte alls. I ett DBMS är behörigheterna finkorniga — ända ner till en enskild tabell:

-- Analytikern får bara läsa ordrar, utan rätt att ändra dem
GRANT SELECT ON orders TO analyst;

• Integritet. Ett DBMS godtar inte en order med ett pris som är text, eller en referens till en köpare som inte finns: kolumntyper och villkor kontrolleras vid varje skrivning. En fil bryr sig inte ett dugg om vad som ligger i den.
• Deklarativa frågor. «Visa ordrar dyrare än 5000» är en rad SQL. Med en fil faller samma jobb på ett program som någon måste skriva — och få rätt.