05 · From Zero to Deployed

Ohne Datenbank vergisst eine App alles, sobald sie stoppt. „Wo liegen die Daten?“ ist eine Frage, die du beim Bauen ständig beantwortest — und dem Agenten vorgibst.

Die Idee

Eine Datenbank ist das Gedächtnis der App — wie ein sehr ordentlicher Aktenschrank. Ohne ihn wäre jeder Instagram-Beitrag nach dem Neuladen verschwunden, jedes Like vergessen.

Wenn du auf Instagram ein Foto postest, wandert die Bildunterschrift in eine Datenbank und das Foto selbst in einen großen Dateispeicher. Tausende Male am Tag, zuverlässig, jahrelang auffindbar — das ist die Arbeit einer Datenbank.

So funktioniert es

Drei Arten, grob:

SQL (Tabelle): wie eine saubere Tabelle mit festen Spalten. Gut für gleichförmige Daten wie Beiträge oder Nutzer.
NoSQL (Dokument): flexible „Zettel“ im JSON-Stil. Gut, wenn die Form oft wechselt.
Blob-/Dateispeicher: für große Dateien (Fotos, Videos).

So legst du in SQL eine posts-Tabelle an — genau mit den Feldern aus unserem Beitrags-Objekt:

CREATE TABLE posts (
  id          TEXT PRIMARY KEY,
  author      TEXT NOT NULL,
  caption     TEXT,
  image_url   TEXT NOT NULL,
  like_count  INTEGER NOT NULL DEFAULT 0,
  created_at  TIMESTAMPTZ NOT NULL DEFAULT now()
);

Ein einzelner Beitrag ist dann eine Zeile:

id	author	caption	image_url	like_count	created_at
p_184029	anna	Sonnenuntergang über Berlin	https://cdn.example/p/a1b2.jpg	12	2026-08-31 09:41

Dasselbe als NoSQL-Dokument wäre einfach das JSON-Objekt aus Lektion 01. Entscheidend in beiden Fällen: Das Foto selbst liegt im Blob-Speicher; die Zeile speichert nur image_url, also den Verweis. Datenbanken sind für Fakten da, nicht für dicke Dateien — ein Foto in eine Tabellenzelle zu legen ist langsam und teuer.

So steuerst du es

Faustregel: gleichförmige, verknüpfte Daten → SQL. Sehr wechselnde Formen → NoSQL. Große Binärdateien → Blob (bei Google: Cloud Storage). Die meisten echten Apps mischen: Instagram würde Beiträge und Likes in SQL halten, die Fotos im Blob-Speicher.

So sagst du es dem Agenten:

„Speichere Beiträge in einer SQL-Tabelle posts mit den Spalten id, author, caption, image_url, like_count, created_at.“

„Lege Fotos im Blob-Speicher ab und speichere in der Datenbank nur image_url, nicht das Foto selbst.“

„Setze like_count mit Default 0 und created_at mit Default now().“

Typische Fehler: Fotos direkt in die Datenbank legen; kein Default für like_count (dann steht dort NULL statt 0); oder vergessen, id als Primärschlüssel zu setzen.

Kurz-Check

Was ist der Unterschied zwischen SQL und NoSQL?
Wo gehört das Foto hin — und was steht in der posts-Zeile?
Warum ist ein Default 0 für like_count sinnvoll?

Antworten anzeigen

SQL: feste Tabellen mit Schema; NoSQL: flexible Dokumente ohne festes Schema.
Das Foto in den Blob-Speicher; in der Zeile steht nur image_url (der Verweis).
Damit ein neuer Beitrag mit 0 statt NULL startet — sonst rechnet und zeigt man mit „nichts“ statt „null Likes“.

Without a database, an app forgets everything the moment it stops. "Where do the data live?" is a question you answer constantly while building — and set for the agent.

The idea

A database is the app's memory — like a very tidy filing cabinet. Without it, every Instagram post would be gone after a reload, every like forgotten.

When you post a photo on Instagram, the caption goes into a database and the photo itself into a large file store. Thousands of times a day, reliably, findable for years — that is the work of a database.

How it works

Three kinds, roughly:

SQL (table): like a clean spreadsheet with fixed columns. Good for uniform data like posts or users.
NoSQL (document): flexible "notes" in JSON style. Good when the shape changes often.
Blob / file store: for large files (photos, videos).

Here is how you create a posts table in SQL — with exactly the fields from our post object:

CREATE TABLE posts (
  id          TEXT PRIMARY KEY,
  author      TEXT NOT NULL,
  caption     TEXT,
  image_url   TEXT NOT NULL,
  like_count  INTEGER NOT NULL DEFAULT 0,
  created_at  TIMESTAMPTZ NOT NULL DEFAULT now()
);

A single post is then a row:

id	author	caption	image_url	like_count	created_at
p_184029	anna	Sunset over Berlin	https://cdn.example/p/a1b2.jpg	12	2026-08-31 09:41

The same as a NoSQL document would simply be the JSON object from lesson 01. The key point in both cases: the photo itself lives in the blob store; the row only stores image_url, the reference. Databases are for facts, not fat files — putting a photo into a table cell is slow and expensive.

How you steer it

Rule of thumb: uniform, related data → SQL. Very changeable shapes → NoSQL. Large binary files → blob (on Google: Cloud Storage). Most real apps mix: Instagram would keep posts and likes in SQL, the photos in the blob store.

How to tell the agent:

"Store posts in a SQL table posts with columns id, author, caption, image_url, like_count, created_at."

"Put photos in the blob store and save only image_url in the database, not the photo itself."

"Set like_count with default 0 and created_at with default now()."

Common mistakes: putting photos into the database; no default for like_count (you then get NULL instead of 0); or forgetting to make id the primary key.

Quick check

What is the difference between SQL and NoSQL?
Where does the photo belong — and what goes in the posts row?
Why is a default of 0 for like_count useful?

Show answers

SQL: fixed tables with a schema; NoSQL: flexible documents without a fixed schema.
The photo into the blob store; the row stores only image_url (the reference).
So a new post starts at 0 instead of NULL — otherwise you compute and display with "nothing" instead of "zero likes".

05 · Datenbanken

05 · Databases