Django ORM nedir ve nasıl çalışır?

04 Kas 22:24

Der Django‑ORM ist im Prinzip ein Mapper zwischen Python‑Klassen und relationalen Tabellen. Jede Klasse, die von `models.Model` erbt, wird beim Laden der App in das Metadaten‑System von Django eingelesen; das Metadaten‑Objekt enthält Felddefinitionen (z. B. `CharField`, `ForeignKey` etc.) und daraus generiert Django automatisch den entsprechenden Tabellen‑ und Spalten‑Schema‑Plan. Der Name der Klasse wird standardmäßig in einen snake_case‑Tabellennamen umgewandelt (oder über `db_table` explizit überschrieben), und Feldnamen werden zu Spaltennamen. Beziehungen werden über spezielle Feldtypen wie `ForeignKey`, `ManyToManyField` und `OneToOneField` definiert – dabei legt Django nicht nur die Fremdschlüssel‑Constraints an, sondern erzeugt auch Hilfs‑Abfragen (z. B. `select_related`, `prefetch_related`), um Joins effizient zu nutzen. Wenn du eine QuerySet‑Methode wie `MyModel.objects.filter(name='Bob')` aufrufst, baut Django zunächst ein internes AST‑ähnliches Objekt auf, das die Filterbedingungen, Order‑ und Limit‑Klauseln enthält. Beim Aufruf von `list(qs)` oder beim Iterieren über das QuerySet wird dieses Objekt vom Query‑Compiler in einen parametrisierten SQL‑String übersetzt und an den konfigurierten Datenbank‑Backend (PostgreSQL, MySQL, SQLite etc.) gesendet. Die Parameter werden sicher über das DB‑API‑Modul gebunden, wodurch SQL‑Injection vermieden wird. Der zurückgelieferte DB‑Cursor wird dann Zeile für Zeile in Modellinstanzen zurückverpackt. Migrations sind das Gegenstück zum Schema‑Management: Jede Änderung an einem Modell (neues Feld, geänderte Option, Umbenennung) erzeugt mit `python manage.py makemigrations` eine neue Migration‑Datei, die als Python‑Code die nötigen DDL‑Operationen (`AddField`, `AlterField`, `RenameModel` …) enthält. Beim Ausführen von `migrate` führt Django diese Operationen in einer Transaktion aus und hält den aktuellen Stand in der Tabelle `django_migrations`. Das ermöglicht ein deterministisches Roll‑Forward‑ und Roll‑Back‑Verhalten, selbst in produktiven Umgebungen. Zur Performance: Der ORM ist für die meisten CRUD‑Szenarien ausreichend schnell, aber er kann bei sehr komplexen Joins oder massiven Bulk‑Operationen zu Overhead führen. Hier helfen `select_related`/`prefetch_related` zur Vermeidung von N+1‑Abfragen, `only`/`defer` zum Laden eines Teilsets von Spalten und `bulk_create`/`bulk_update` für massenhafte Inserts/Updates. Außerdem lässt sich bei kritischen Pfaden das erzeugte SQL mittels `str(qs.query)` inspizieren und bei Bedarf mit einem Raw‑Query oder einem benutzerdefinierten Manager überschreiben. So bleibt das System flexibel, ohne die Lesbarkeit und Wartbarkeit, die das ORM von Haus aus bietet, zu verlieren.

04 Kas 23:13

Django‑ORM funktioniert ähnlich wie andere objekt‑relational‑Mapper, etwa SQLAlchemy in Python: Jede `models.Model`‑Klasse wird beim Starten des Projekts in eine Datenbank‑Tabelle übersetzt, wobei Feld‑Attribute (`CharField`, `ForeignKey` usw.) zu Spalten und deren Typen werden automatisch gemappt. Beim Erzeugen oder Ändern einer Model‑Klasse erzeugt `makemigrations` ein Migrations‑File, das die nötigen DDL‑Statements (CREATE / ALTER TABLE) enthält; `migrate` führt diese dann auf die konfigurierte Datenbank aus. Im Gegensatz zu reinem SQL‑Code musst du die Tabellenstruktur nie von Hand schreiben – das Framework hält das Schema und den Code stets synchron. Die eigentlichen Abfragen werden über das QuerySet‑API gebaut (z. B. `User.objects.filter(active=True).order_by('-last_login')`). Intern wandelt Django das QuerySet in einen parametrisierten SQL‑String um und nutzt dabei den Datenbank‑Backend‑Adapter, sodass dieselbe Logik auf PostgreSQL, MySQL oder SQLite läuft. Im Vergleich zu einem manuellen SQL‑Ansatz spart das viel Boilerplate, aber du verlierst etwas Feinkontrolle: komplexe Joins oder CTEs können in Django‑ORM umständlich sein, während SQLAlchemy Core dir fast unveränderten SQL‑Zugriff ermöglicht. Performance‑technisch ist Django‑ORM meist ausreichend – das erzeugte SQL ist effizient, solange du Indexe auf häufig gefilterte Felder setzt und `select_related`/`prefetch_related` nutzt, um N+1‑Abfragen zu vermeiden. Für extrem optimierte oder datenbank‑spezifische Features greift man dann auf rohe SQL‑Ausdrücke (`raw()`) oder ein alternatives ORM zurück.