Spring GDS 25. Jubiläum
Ein Logistikunternehmen, das in 190 Länder versendet, hat etwas gebaut, um an sich selbst zu liefern.
Object-Relational Mapping ist eine Schicht, mit der Sie über die Objekte Ihrer Programmiersprache statt über rohes SQL mit einer relationalen Datenbank arbeiten. Eine Zeile in einer Benutzertabelle wird zu einem User-Objekt. Lesen, Anlegen und Aktualisieren von Datensätzen läuft über Methodenaufrufe, und das ORM erzeugt das SQL darunter. Datenbankspalten werden auf Objektfelder abgebildet, Beziehungen auf Referenzen zwischen Objekten.
Der Sinn ist, Entwickler in einem mentalen Modell zu halten. Sie denken in Objekten und Beziehungen, nicht in Joins und Tabellenaliassen, und das ORM übernimmt auch mühsame, fehleranfällige Details wie das Escapen von Eingaben, um SQL-Injection zu verhindern. Der Preis ist eine Abstraktionsschicht, die verbergen kann, was die Datenbank tatsächlich tut. Die klassische Falle ist das N+1-Abfrageproblem: Eine Liste laden und dann die Beziehungen jedes Eintrags anfassen löst Hunderte kleiner Abfragen aus statt eines effizienten Joins. Ein Team, das 50 Blogbeiträge mit ihren Autoren auflistet, kann über ein ORM versehentlich 51 Abfragen auslösen, wo ein einziger Join genügt hätte, sofern es dem ORM nicht sagt, die Beziehung vorab zu laden.
Prisma, TypeORM, Drizzle, Sequelize, Hibernate und das ORM von Django sind gängige Beispiele. Die meisten erlauben den Wechsel zu rohem SQL für die Abfragen, die die Abstraktion schlecht löst.
Wir nutzen ein ORM für den Großteil des Datenzugriffs einer Anwendung, denn es macht die häufigen Fälle schnell zu schreiben, sicher gegen Injection und Monate später leicht zu lesen. Seinen Wert zeigt es bei den neunzig Prozent der Abfragen, die unkompliziert sind. Die Disziplin liegt darin, zu wissen, dass es die anderen zehn Prozent gibt, und nicht so zu tun, als sei die Datenbank verschwunden, nur weil ein ordentliches Objekt davor steht.
Deshalb beobachten wir die Abfragen, die ein ORM tatsächlich erzeugt, besonders die N+1-Muster, die im Code harmlos aussehen und eine Datenbank unter realer Last erdrücken. Für die schweren Berichte und komplexen Aggregationen, bei denen ein ORM gegen das Problem ankämpft, wechseln wir zu handgeschriebenem SQL und halten es lesbar. Diese Balance aus Produktivität und Kontrolle zieht sich durch unsere individuelle Webanwendungsentwicklung und unsere Webentwicklung, wo die Datenschicht still entscheidet, ob ein Produkt schnell bleibt, während es wächst.
Wird Ihre Anwendung langsamer, je mehr Daten wachsen? Oft ist die Abfrageschicht die Ursache. Schauen wir es uns an.
Ein Logistikunternehmen, das in 190 Länder versendet, hat etwas gebaut, um an sich selbst zu liefern.
Eine Marke in ein funktionierendes Geschäft verwandeln.
Eine halbe Million Menschen. Eine App. Null Chaos.















