MB Dev .tech
Registrieren Login

PHP + DB Praxis · Form → DB Flow

← Zurück zu PHP + DB Praxis

Jetzt verbinden wir zwei Welten: Ein Benutzer füllt ein Formular aus (Browser), PHP nimmt die Daten entgegen (Server) und speichert sie in der Datenbank. Dieser Ablauf ist der Kern fast jeder Web-App.

Merke
Ein Formular ist nur der Startpunkt

Entscheidend ist, was der Server daraus macht: prüfen, säubern, speichern und anschließend sinnvoll reagieren.

1) Der typische Ablauf (Schritt für Schritt)

  1. Browser zeigt Formular (GET)
  2. Benutzer füllt aus und sendet ab (POST)
  3. Server liest $_POST
  4. Server validiert (Stimmt die Eingabe?)
  5. Server speichert mit Prepared Statement (INSERT/UPDATE)
  6. Server antwortet sinnvoll (z.B. Redirect oder Erfolgsmeldung)
Tipp
Denke in Requests

Web ist nicht „ein Programm, das durchläuft“, sondern viele einzelne Requests. Jeder Request startet neu und hat seinen eigenen Input.

2) Beispiel-Szenario: Kontaktformular → Tabelle

Wir nehmen als Praxis-Beispiel eine einfache Tabelle für Kontaktanfragen. Jeder Eintrag enthält Name, E-Mail und Nachricht.

SQL Tabelle (Beispiel)

CREATE TABLE contact_messages (
  id INT AUTO_INCREMENT PRIMARY KEY,
  name VARCHAR(80) NOT NULL,
  email VARCHAR(180) NOT NULL,
  message TEXT NOT NULL,
  created_at DATETIME NOT NULL
);
Merke
Datenbank speichert dauerhaft

Nach einem Request ist PHP „weg“ – die Datenbank bleibt. Genau deshalb speichern wir dort.

3) Formular anzeigen (GET)

Beim ersten Aufruf der Seite (GET) möchtest du meistens nur das Formular anzeigen. Erst beim Absenden (POST) passiert die Speicherung.

HTML Formular (Beispiel)

<form method="post">
  <label>Name</label>
  <input name="name">

  <label>E-Mail</label>
  <input name="email">

  <label>Nachricht</label>
  <textarea name="message"></textarea>

  <button type="submit">Senden</button>
</form>
Achtung
Ein HTML-Formular ist keine Sicherheit

Selbst wenn du Felder im Browser „pflichtig“ machst: Auf dem Server musst du trotzdem alles prüfen. Browser-Regeln kann man umgehen.

4) POST verarbeiten: Validieren → Speichern

Jetzt kommt der typische Kern: Du prüfst, ob es ein POST ist, liest Werte aus $_POST, validierst sie und speicherst sie dann mit einem Prepared Statement.

PHP Ablauf (Beispiel)

$errors = [];

if ($_SERVER['REQUEST_METHOD'] === 'POST') {
    $name    = trim((string)($_POST['name'] ?? ''));
    $email   = trim((string)($_POST['email'] ?? ''));
    $message = trim((string)($_POST['message'] ?? ''));

    // 1) Validierung (sehr einfach)
    if ($name === '') {
        $errors[] = "Name ist Pflicht.";
    }
    if ($email === '' || strpos($email, '@') === false) {
        $errors[] = "Bitte gib eine gültige E-Mail an.";
    }
    if ($message === '') {
        $errors[] = "Nachricht ist Pflicht.";
    }

    // 2) Speichern nur, wenn keine Fehler
    if (empty($errors)) {
        $sql = "
          INSERT INTO contact_messages (name, email, message, created_at)
          VALUES (:name, :email, :message, NOW())
        ";

        $stmt = $pdo->prepare($sql);
        $stmt->execute([
            ':name'    => $name,
            ':email'   => $email,
            ':message' => $message,
        ]);

        $success = true;
    }
}
Merke
Erst validieren, dann speichern

Wenn du sofort speicherst und erst danach prüfst, bekommst du kaputte Daten in die Datenbank. Das räumt man später nur mühsam wieder auf.

5) Das PRG-Pattern (Post/Redirect/Get)

Ein sehr wichtiges Muster in Web-Apps ist PRG: Nach einem erfolgreichen POST leitest du um (Redirect) und zeigst danach die Seite per GET.

Warum? Damit beim Neuladen der Seite nicht nochmal derselbe POST abgeschickt wird. Sonst entstehen doppelte Einträge.

PRG (vereinfacht)

if (empty($errors)) {
    // speichern...

    header("Location: /kontakt.php?sent=1");
    exit;
}
Tipp
PRG verhindert Doppeleinträge

Wenn du jemals „Warum habe ich plötzlich alles doppelt?“ hattest: PRG ist sehr oft die Lösung.

6) Typische Fehler beim Form → DB Flow

  • Keine Validierung → kaputte Daten
  • SQL-Strings zusammenkleben → SQL-Injection-Risiko
  • Kein Redirect nach POST → Doppeleinträge bei Reload
  • Fehler/Erfolg nicht klar anzeigen → Nutzer weiß nicht, was passiert ist
Achtung
Sanitizing ist nicht gleich Escaping

Daten „säubern“ (trim, Länge prüfen, Format prüfen) ist etwas anderes als Ausgabe-Escaping. Beides ist wichtig – aber an unterschiedlichen Stellen.

Kleine Aufgaben (zum Mitdenken)

Aufgabe 1: Warum ist PRG nützlich?

Was könnte passieren, wenn du nach dem Speichern keinen Redirect machst und der Nutzer die Seite neu lädt?

Lösung einblenden
Lösung
Der POST wird erneut gesendet → Doppelter Eintrag

Browser warnen manchmal („Formular erneut senden?“), aber viele klicken auf „OK“. PRG verhindert das Problem sauber.