ORM vs Raw SQL 🪑

Der ewige Holywar, bei dem die einen für „Bequemlichkeit“ und die anderen für „Kontrolle“ plädieren.

🪑 Stuhl Nr. 1: SQLAlchemy ORM

ORM geht nicht um Code-Geschwindigkeit, sondern um die Geschwindigkeit der Feature-Auslieferung. Sie arbeiten mit Objekten, nicht mit Strings.

✅ Warum das cool ist:
— Unit of Work: Alchemy überwacht selbstständig Änderungen an Objekten und schiebt sie in einem einzigen Transaktionspaket in die Datenbank.
— Sicherheit: SQL-Injection? Vergessen Sie es. Wenn Sie kein .text() verwenden, sind Sie standardmäßig geschützt.
— Migrationen: Die Synchronisation des DB-Schemas mit Ihren Modellen ist pure Magie, die Stunden an Routinearbeit spart.
— Domain Logic: Ideal für komplexe E-Commerce-Systeme und Admin-Oberflächen, bei denen die Beziehungen zwischen Tabellen verworrener sind als die Handlung von „Interstellar“.

❌ Der Haken:
— Overhead: Das Mapping von Objekten ist eine teure Operation. Bei großen Abfragen (100k+ Zeilen) werden Sie spüren, wie der Python-Prozess Speicher und CPU frisst.
— N+1-Problem: Der Hauptkiller der Performance. Ein vergessenes .joinedload() und Ihr Service bricht unter einem Hagel kleiner Abfragen zusammen.

🪑 Stuhl Nr. 2: Raw SQL / asyncpg (Die Wahl für Highload)

Wenn Sie an die Leistungsgrenze stoßen, stören die Zwischenschichten.

✅ Warum das cool ist:
— Extreme Geschwindigkeit: Ein Unterschied von 2,5-fach ist kein Scherz. Das binäre Protokoll von asyncpg ermöglicht es, das Maximum aus dem Netzwerkkanal herauszuholen.
— Volle Kontrolle: Sie schreiben genau das SQL, das in den Datenbankplaner geht. Keine zusätzliche Magie vom ORM.
— Spezifische DB-Features: Versuchen Sie, JSONB oder spezifische Postgres-Indizes effizient über ORM zu nutzen – das wird manchmal zur Sisyphusarbeit.

❌ Der Haken:
— Ihre Verantwortung: Parameter-Escaping vergessen? Herzlichen Glückwunsch, die Datenbank ist kompromittiert.
— Boilerplate: Sie müssen Tupel aus der Datenbank manuell in DTO/Pydantic-Modelle mappen. Das ist langweilig und führt zu Fehlern.
— Wartbarkeit: 500 Zeilen rohes SQL im Code nach einem halben Jahr zu lesen, ist fragwürdiges Vergnügen.


💡 Fazit: Der Goldstandard ist ein hybrider Ansatz

Sie müssen sich nicht für eines entscheiden. Die moderne Architektur sieht so aus:
1. SQLAlchemy ORM – für 90% der Aufgaben: CRUD, Geschäftslogik, Migrationen und Admin.
2. SQLAlchemy Core – wenn ORM-Objekte zu schwer sind, Sie aber noch keine rohen Strings schreiben möchten.
3. Raw SQL (asyncpg) – für Engpässe: Analyseberichte, Massen-Inserts und Microservices mit einer Last von 10k+ RPS.

Wählen Sie den Stuhl nach der Lastgröße ☝️

Und womit schreiben Sie?
👨‍💻 Nur ORM, das Leben ist zu kurz, um SQL von Hand zu schreiben.
👨‍💻 Nur Raw SQL, ich vertraue dieser Magie nicht.

#zwei_stuehle