SQLite Parameter Binding: ? und :name richtig nutzen

Binding: So gelangen Werte in ein Prepared Statement

Ein Prepared Statement ist SQL mit Lücken. Binding – also das Binden von Parametern – bedeutet, diese Lücken mit Werten zu füllen. Und zwar sauber, Wert für Wert, über die API des Treibers, statt Strings zusammenzubasteln.

Das Muster ist immer dasselbe: Du schreibst das SQL mit Platzhaltern und übergibst die Werte separat.

CREATE TABLE users (
    id    INTEGER PRIMARY KEY,
    name  TEXT NOT NULL,
    email TEXT
);

-- Das SQL, das die Datenbank sieht:
INSERT INTO users (name, email) VALUES (?, ?);

In der CLI lässt sich Parameter Binding nicht wirklich zeigen (die Shell hat ja keinen App-Code im Hintergrund), aber das SQL oben ist exakt das, was deine Anwendung an SQLite schickt. Die ? sind Platzhalter. Dein Treiber — sqlite3 in Python, better-sqlite3 in Node, rusqlite in Rust — füllt sie über einen separaten bind-Aufruf mit Werten.

Die Vorstellung dahinter: Das SQL ist das Rezept, die gebundenen Werte sind die Zutaten. Beide kommen nie direkt miteinander in Berührung.

Positionsbasierte Platzhalter: ?

Der einfachste Platzhalter ist ?. Jedes ? wird der Reihe nach mit dem nächsten Wert befüllt, den du bindest.

INSERT INTO users (name, email) VALUES (?, ?);

In Python sieht das so aus:

cursor.execute(
    "INSERT INTO users (name, email) VALUES (?, ?)",
    ("Rosa", "rosa@example.com"),
)

Das erste ? bekommt "Rosa", das zweite "rosa@example.com". Wenn du zu wenige oder zu viele Werte übergibst, meldet sich der Treiber mit einem Fehler, bevor das Statement überhaupt ausgeführt wird.

Du kannst die Platzhalter aber auch explizit durchnummerieren – mit ?1, ?2, ?3. Das ist praktisch, wenn derselbe Wert mehrfach vorkommt:

SELECT ?1 AS gruss, ?1 AS immer_noch_dasselbe;

?1 verwendet den ersten gebundenen Wert wieder. Ohne Nummerierung müsstest du denselben Wert zweimal binden.

Benannte Platzhalter: :name

Sobald ein Statement mehr als zwei oder drei Lücken hat, wird positionsbasiertes Binden zum Ratespiel. Benannte Parameter schaffen Abhilfe:

INSERT INTO users (name, email)
VALUES (:name, :email);

In Python:

cursor.execute(
    "INSERT INTO users (name, email) VALUES (:name, :email)",
    {"name": "Boris", "email": "boris@example.com"},
)

Die Reihenfolge der Keys im Dictionary spielt keine Rolle — entscheidend sind nur die Namen. SQLite akzeptiert auch @name und $name als alternative Präfixe; alle drei verhalten sich identisch. In der Praxis siehst du aber fast immer :name.

Benannte Parameter zeigen ihre Stärke spätestens dann, wenn du ein UPDATE über fünf Spalten schreibst oder denselben Wert in WHERE und RETURNING brauchst.

NULL in SQLite binden

Um NULL einzufügen, übergibst du einfach den Null-Wert deiner Programmiersprache an die Binding-API. Den Rest erledigt der Treiber:

INSERT INTO users (name, email) VALUES (?, ?);
-- Bind: ("Cyrus", None)   in Python
-- Bind: ["Cyrus", null]   in Node

SELECT id, name, email FROM users;

None, null, nil – egal, wie deine Sprache es nennt: Der Treiber macht daraus ein echtes SQL-NULL. Binde bloß nicht den String "NULL", sonst landet bei dir der vierstellige Text "NULL" in der Datenbank. Und schreib das Wort NULL auch nicht direkt in den SQL-Text – damit hebelst du das ganze Binding aus.

Genauso läuft es mit Zahlen, Blobs und Datumswerten: Übergib den nativen Wert und überlass das Binden dem Treiber.

Ein Prepared Statement mehrfach mit verschiedenen Werten nutzen

Parameter Binding und Prepared Statements gehören in SQLite zusammen wie Topf und Deckel. Einmal vorbereiten, dann beliebig oft mit neuen Werten ausführen. Der Parser arbeitet nur ein einziges Mal, und die Datenbank wiederverwendet den kompilierten Ausführungsplan für jedes gebundene Werte-Set.

INSERT INTO users (name, email) VALUES (?, ?);
-- Bind ("Ada",   "ada@example.com")    -> ausführen
-- Bind ("Boris", "boris@example.com")  -> ausführen
-- Bind ("Cyrus", NULL)                 -> ausführen

SELECT id, name, email FROM users ORDER BY id;

Die meisten Treiber kapseln das in einem executemany (Python) oder einer .run()-Schleife (Node). So oder so sparst du dir den Parsing-Aufwand — pro Statement nicht der Rede wert, aber spürbar, wenn du tausende Zeilen einfügst.

Platzhalter-Stile nicht im selben Statement mischen

Technisch erlaubt SQLite zwar, positionale und benannte Platzhalter im selben Statement zu kombinieren. Lass es trotzdem sein.

-- Erlaubt, aber eine Falle:
INSERT INTO users (name, email) VALUES (?, :email);

Beim Lesen muss man sonst zwei Binding-APIs gleichzeitig im Kopf behalten, und die meisten Treiber kommen mit der gemischten Variante eh nicht sauber klar. Entscheide dich also pro Statement für einen Stil: ? für ein oder zwei Werte, :name für alles andere.

Eine typische Falle: Parameter-Binding ist kein String-Formatting

Der ganze Sinn vom Binding ist ja gerade, dass die Werte nicht durch den SQL-Parser laufen. Schau dir mal diese beiden Python-Zeilen im Vergleich an:

# Falsch – String-Formatierung:
cursor.execute(f"SELECT * FROM users WHERE name = '{name}'")

# Richtig – Parameterbindung:
cursor.execute("SELECT * FROM users WHERE name = ?", (name,))

Die erste Zeile baut SQL per String-Konkatenation zusammen. Steht in name jetzt "'; DROP TABLE users; --", parst und führt die Datenbank das eingeschleuste Statement seelenruhig aus. Die zweite Zeile dagegen schickt SQL und Wert über getrennte Kanäle – der Wert wird als String gebunden, fertig, egal welche Zeichen er enthält. Genau deshalb predigt dir jede Anleitung das Binden von Parametern: Es geht nicht um Stil, sondern darum, was der Parser tatsächlich zu sehen bekommt.

Auf der nächsten Seite schauen wir uns die Injection-Seite davon noch genauer an.

Noch ein Stolperstein: Bezeichner lassen sich nicht binden

Platzhalter funktionieren nur für Werte – also Strings, Zahlen, Blobs, NULLs. Für Tabellennamen, Spaltennamen oder SQL-Schlüsselwörter sind sie tabu:

-- Das macht NICHT, was du möchtest:
SELECT * FROM ? WHERE id = ?;
-- Das erste ? wird als String-Literal gebunden, nicht als Tabellenname.

Wenn du wirklich einen dynamischen Tabellen- oder Spaltennamen brauchst (in Anwendungscode eher selten), prüfe ihn gegen eine Allowlist und setze ihn selbst in das SQL ein – aber niemals direkt aus Nutzereingaben. Für alles andere gilt: binden statt einsetzen.

Ein durchgängiges Beispiel

Jetzt fügen wir alles zusammen – eine kleine users-Tabelle, die komplett über parametrisierte Queries geschrieben und gelesen wird:

CREATE TABLE users (
    id      INTEGER PRIMARY KEY,
    name    TEXT NOT NULL,
    email   TEXT,
    active  INTEGER NOT NULL DEFAULT 1
);

-- Die Anwendung würde diese Werte binden; hier als Literale dargestellt:
INSERT INTO users (name, email)        VALUES ('Ada',   'ada@example.com');
INSERT INTO users (name, email)        VALUES ('Boris', 'boris@example.com');
INSERT INTO users (name, email, active) VALUES ('Cyrus', NULL, 0);

-- Echte Abfrage, die ein Treiber ausführen würde, mit gebundenen :name und :active:
SELECT id, name, email
FROM users
WHERE active = :active AND name LIKE :name
ORDER BY id;

In echtem Code würden sowohl die INSERTs als auch das SELECT mit Platzhaltern arbeiten. Die CLI hat eben keine App, aus der gebunden werden könnte, deshalb stehen hier Literale stellvertretend für das, was beim Binding sonst rauskommt.

Als Nächstes: SQL-Injection verhindern

Parameter-Binding ist das Werkzeug. Warum es SQL-Injection ausbremst – und in welchen wenigen Fällen Binding allein nicht ausreicht – ist das Thema der nächsten Seite.