Ist O/R Mapping es wert?

Question

Die Ausdruckskraft der Abfragesprachen (QL) von ORMs kann sehr leistungsstark sein. Leider, sobald Sie eine Vielzahl von komplexen Abfragen haben und dann ein verwirrendes Schema- oder Datenproblem auftritt, ist es sehr schwierig, die Unterstützung des Datenbankadministrators (DBA) zu erhalten, die Sie benötigen? Hier sind sie, Teil des Teams, das die Datenbank weiterentwickelt, aber sie können die Anwendungs-QL nicht lesen, geschweige denn Änderungen vorschlagen. Normalerweise greife ich dann auf das generierte SQL aus dem Protokoll zurück. Aber wenn sie Änderungen daran empfehlen, wie verhält sich das zu der ursprünglichen QL? Der Prozess ist kein Round-Trip.

Also, nach einem Jahrzehnt, in dem ich den Wert von ORMs gefördert habe, frage ich mich jetzt, ob ich mein SQL manuell schreiben sollte. Und vielleicht möchte ich wirklich, dass das Framework die Datenmarshalisierung so weit wie möglich automatisiert.

Frage: Haben Sie einen Weg gefunden, mit dem Hin- und Herbewegungsproblem in Ihrer Organisation umzugehen? Gibt es ein SQL-Marshal-Framework, das gut skaliert und leicht zu pflegen ist?

(Ja, ich weiß, dass reines SQL mich an den Datenbankanbieter binden könnte. Aber es ist möglich, standardskonformes SQL zu schreiben.)

Answer 1

Ich denke, dass das, was du möchtest, eine Lösung ist, die die Vorteile von ORM maximiert, ohne dich daran zu hindern, auch andere Mittel zu verwenden. In unserer Anwendung haben wir so ziemlich dasselbe Problem wie du; sehr umfangreiche Abfragen und ein großes Datenmodell. Angesichts der Größe des Datenmodells ist ORM für den Großteil der Anwendung von unschätzbarem Wert. Es ermöglicht uns, das Datenmodell zu erweitern, ohne uns große Mühe bei der manuellen Pflege von SQL-Skripts machen zu müssen. Darüber hinaus, und das hast du angesprochen, unterstützen wir vier Datenbankanbieter, also ist die Abstraktion praktisch.

Es gibt jedoch Situationen, in denen wir die Abfragen manuell optimieren mussten, und da wir uns für eine flexible ORM-Lösung entschieden haben, können wir das auch tun. Wie du sagst, stört es uns nicht, wenn wir es loswerden wollen, und macht einfach Objekte für uns verfügbar.

Also, kurz gesagt (ja, wirklich kurz), ja, ORM lohnt sich, aber wie bei jeder Lösung für ein Problem ist es kein Allheilmittel.

Answer 2

Im Allgemeinen erhöhen ORMs die Produktivität der Entwickler erheblich, daher würde ich sie verwenden, es sei denn, sie sind zu einem größeren Problem geworden, als sie wert sind. Wenn die Mehrheit Ihrer Tabellen groß genug ist, dass Sie viele Probleme haben, erwägen Sie, das ORM aufzugeben. Ich würde auf jeden Fall nicht sagen, dass ORMs im Allgemeinen eine schlechte Idee sind. Die meisten Datenbanken sind klein genug und die meisten Abfragen sind einfach genug, dass sie gut funktionieren.

Ich habe dieses Problem überwunden, indem ich nur gespeicherte Prozeduren oder von Hand geschriebenes SQL für die schlecht performanten Abfragen verwendet habe. Datenbankadministratoren lieben gespeicherte Prozeduren, da sie sie ohne Ihre Zustimmung ändern können. Die meisten (wenn nicht alle) ORMs erlauben es Ihnen, handgeschriebenes SQL oder gespeicherte Prozeduren einzumischen.

Answer 3

Die heutigen O/R-Frameworks unterstützen die Möglichkeit, einige Abfragen manuell zu definieren ((N)Hibernate tut dies). Diese können für komplexe Teile von Schemas verwendet werden, während für einfache Teile das ORM des Frameworks verwendet wird.

Etwas, das du dir vielleicht ansehen möchtest, ist das iBatis-Framework (http://ibatis.apache.org/). Ich habe es nicht benutzt, aber ich habe gelesen, dass es mehr SQL-orientiert ist und Leute, die mit Datenbanken und SQL vertraut sind, es einem umfassenden ORM-Framework wie Hibernate vorziehen, da es ihnen näher steht als das komplett andere Konzept eines ORMs.