Eine kurze Befragung von Kollegen zu meinem aktuellen Projekt ergab, dass mit den Worten "ORM und Arbeiten mit der Datenbank" in den allermeisten Fällen die Worte "Alchemie" und "Django ORM" klingen. Die Kenntnis dieser beiden Wörter reicht im Allgemeinen aus, um sauberen, ordentlichen und funktionierenden Code zu schreiben. Die Erweiterung des technischen Horizonts hat bisher noch niemandem geschadet. Deshalb werden wir heute ein paar (vielleicht bis heute unbekannte) coole Stücke für die Arbeit mit der Datenbank zu unserem Bild der Welt hinzufügen.
Yoyo
Heutzutage verfügt jeder ORM über ein internes Datenbankmigrationssystem. Ein einfacher und cooler Ansatz, bei dem ORM die Struktur von Tabellen im Allgemeinen überwacht, ist für jeden geeignet. Diese Lösung hat jedoch einen Fall, in dem die Verwendung unpraktisch ist:
Es gibt Leute, die Anfragen in einer Datenbank unter Umgehung von ORM stellen. Dies verwendet so etwas wie Asyncpg und einen kleinen selbstgeschriebenen Fleck, um das Zusammenstellen von Anforderungen zu vereinfachen.
Warum geben diese Leute die ORM-Annehmlichkeiten auf? Ja, da jeder Wrapper für die Datenbank eine bestimmte Menge an Systemressourcen verbraucht und diese Leute Hochleistungscode schreiben müssen. Sie haben ORM rausgeschmissen und müssen irgendwie die Basis migrieren.
- Integrierte Migranten haben möglicherweise ihre eigenen spezifischen Ansichten zum Verknüpfen und Indizieren von Datensätzen. Manchmal ist es nicht möglich, diese ORM-Ansichten für die Struktur von Tabellen zu deaktivieren.
In beiden Fällen ist es praktisch, manuelle Migrationen zu verwenden. Wir verlassen uns nicht auf ORM-Modelle, sondern geben mit unseren Händen die erforderlichen SQL-Anweisungen ein und geben sie in einen einfachen Migrator ein, der nacheinander strukturelle Änderungen an der Datenbank anwendet.
Die Ausgabe ist eine saubere, verständliche und vollständig verwaltbare Tabellenstruktur, die mit Bedacht kompiliert wurde.
Für einen solchen manuellen Ansatz gibt es einen Yoyo- Datenbankschema-Migrator.
pip install yoyo-migrations
Als Nächstes werden alle Migrationsverwaltungsarbeiten mit der ausführbaren Datei yoyo ausgeführt
yoyo new ./migrations -m "Add column to foo"
Der Befehl erstellt eine Datei, in die Sie eine oder mehrere Anweisungen zum Migrieren des Schemas eingeben können
from yoyo import step steps = [ step("CREATE TABLE foo (id INT, bar VARCHAR(20), PRIMARY KEY (id))", "DROP TABLE foo"), ]
Nach dieser Migration können Sie zur Basis rollen
yoyo apply --database postgresql://scott:tiger@localhost/db ./migrations
Alles ist einfach, wie Protokolle. Gleichzeitig haben Sie die vollständige Kontrolle darüber, wie die Datenbank aussieht.
Dieser Ansatz hat zwei Nachteile.
- Auf die Felder in den Tabellen und ihre Parameter müssen Handles folgen. Jede Änderung führt dazu, dass Sie ALTER TABLE selbst schreiben müssen. Die Möglichkeit, alles mit einem Klick zu migrieren, geht verloren.
- Das Zusammenführen solcher Migrationen muss auch immer mit Händen und Kopf erfolgen. Das ist natürlich überflüssige Arbeit. In der Praxis sind Konflikte und komplexe Zusammenschlüsse von Migration jedoch selten.
Peewee
Ein kleines und nicht das beliebteste ORM (obwohl hier schon mehr als einmal darüber geschrieben wurde), das jedoch ein eigenes Publikum hat.
Peewee wurde entwickelt, um der dümmste und einfachste Wrapper für die Datenbank zu sein, mit dem verständlichsten Mechanismus zur Ausführung von Abfragen und einfach zu lesendem Code.
Users.select().where( Users.user_id == user_id ).get()
Trotz seiner Einfachheit, seines Minimalismus und einer geringen Menge an Code verfügt Peewee über alles, was für eine vernünftige Arbeit erforderlich ist.
- Angemessene Leistung (obwohl nicht die schnellste Abfrageausführungsgeschwindigkeit)
- Alle notwendigen Extras - verschiedene Sätze von Feldern, Beziehungen zwischen Entitäten, Verbindungspools, Sätze von Plugins und Erweiterungen.
- Das peewee_async- Modul eines Drittanbieters fügt noch mehr oder weniger vernünftige Asynchronität hinzu.
Pony orm
Pony ist eine legendäre Hülle. Die mit diesem ORM geschriebene Datenbankschicht kann zeitweise die Rückseite anderer Lösungen beschleunigen. Es gibt keine Magie in seiner Geschwindigkeit, es gibt eine sehr kompetente Richtlinie zum Zwischenspeichern von Anforderungen an die Datenbanken, jede Menge Optimierungen und Tricks mit dem Code. Insgesamt führt dies dazu, dass das Pony mit Pferdegeschwindigkeit brät.
Das Minus kann in diesem ORM als Abfragesyntax bezeichnet werden - es ist sehr spezifisch und verwendet Generatoren, Lambdas und andere Python-Sprachbrötchen.
query = select(c for c in Customer if sum(o.total_price for o in c.orders) > 1000) Product.select().order_by(lambda p: desc(sum(p.order_items.quantity))).first()
Dieser Ansatz erfordert einen gewissen Zusammenbruch des Gehirns.
Schildkröte orm
Als ich mich mit verschiedenen tierfreundlichen Repos befasste, fand ich eine Sammlung von Tests verschiedener ORMs mit Geschwindigkeitsmessungen. Zusätzlich zum bereits erwähnten Pony ORM erschien ein bestimmter Tortoise ORM in der Liste der schnellsten. Es ist klar, dass die Testergebnisse davon abhängen, wer die Tests schreibt und wie sie dann ausgeführt werden, aber Sie müssen sich diese Sache genauer ansehen.
Tortoise ist ein relativ junges Projekt, das sich noch in der aktiven Entwicklung befindet. Die gute Leistung dieser Bibliothek erklärt sich aus der Tatsache, dass ORM nichts Überflüssiges enthält und sofort für den asynchronen Betrieb eingesperrt ist. Außerdem wird die Verwendung von uvloop vorausgesetzt , das schneller arbeitet als die nativen Piton-Zyklen von Ereignissen.
Dieses ORM ist immer noch zu roh, um im Kampf verwendet zu werden (zum Beispiel bis Verbindungspools überhaupt implementiert sind), aber Sie sollten sich die Entwicklung dieser Bibliothek ansehen. Wenn alles gut mit den Entwicklern läuft, werden wir im kommenden Jahr einen wirklich schnellen Wrapper für die Datenbank mit guter Geschwindigkeit und ohne seltsame Syntax im Stil von Pony bekommen.