Über ORM

ORM ist an sich eine feine Sache. Durch die zusätzliche Abstraktionsschicht ist man so gut wie vollkommen datenbankunabhängig. Weiterhin hat man einen sauberen OOP Ansatz duchgehend im Projekt ohne hässliche SQL Statements dazwischengemischt zu haben. Es fühlt sich sehr „smooth“ an und steigert – richtig gemacht – auch durchaus die Verständlichkeit des Codes.

Trotzdem bin ich nicht in allen Belangen großer Freund von ORM. Neulich hatte ich mit einer Tabelle zu tun, in der mehrere Millionen Tupel enthalten waren. Ein falsch platzierter Index oder der kleinste Fehler bei der Formulierung der Query führt dazu, dass man mehrere Minuten auf das Ergebnis der Abfrage warten darf. Noch schlimmer könnte auch gleich Filesort verwendet werden.Das führt bei einer derartigen Tabellengröße direkt mal dazu, dass die Platte komplett vollgeschrieben wird. Was hat diese Anekdote jetzt mit ORM zu tun? Bei „kritischen“ SQL-Statements wird ein ORM nie so zielgerichtete Queries formulieren können, dass die Performance mit einer handgeschriebenen mithalten
könnte. Alles, was mehr ins Detail geht kann mit einem ORM sehr schnell haklig werden oder wird zumindest unverhältnismäßig komplizierter.

Zum ORM-Pluspunkt „Unabhängigkeit von der Datenbankengine“ lässt sich erwidern, dass man mit PDO ohnehin mit dem überwiegenden Teil der Datenbanken kommunizieren kann, ohne schmerzliche Änderungen bei einem DB-Wechsel vornehmen zu müssen. Bleibt noch der zusätzliche Installationsaufwand und Performanceverlust durch den „OOP-Overhead“ bei der Verwendung von ORM hängen.

Letztendlich darf ich dann noch eine neue Abfrage-Sprache lernen (etwa DQL). Das kann man sicher alles verkraften und in Kauf nehmen, ich sag auch auf keinen Fall das von ORM generell abzuraten ist. Ich favorisiere daher eine selbstgeschriebene ORM-Lösung die man an den benötigten Stellen bequem anpassen und zum Einsatz bringen kann. Das erhöht die Flexibilität merklich (individuelles Eingehen auf die vorliegende Situation), steigert die Perfomance (keinen nicht benötigten Ballast) und durch ein Aufsetzen auf PDO ist man letztendlich doch noch flexibel genug.

Einen Ansatz dazu werde ich evtl. mal in naher Zukunft diskutieren.

Weitere Posts:

Dieser Beitrag wurde unter Datenbanken, Software Engineering, Performance, webdev veröffentlicht. Setze ein Lesezeichen auf den Permalink.

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.