Ist ORM ein schlechtes Werkzeug für baumartige DB-Strukturen?

Ich weiß, dass diese Frage möglicherweise als meinungsbasiert geschlossen wird, aber was ich jetzt brauche, sind einige Meinungen, die durch Argumente gestützt werden.

Ich erstelle eine Anwendung mit Postgres und Ecto (Elixier) als Persistenzschicht. Es gibt eine Entität, die auf sich selbst verweist, sodass Sie damit eine baumartige Struktur erstellen können. Je mehr ich versuche, dies mit Ecto zu tun, desto frustrierter werde ich.

Sind ORMs einfach ein schlechtes Werkzeug zum Erstellen komplexer DB-Strukturen mit vielen Assoziationen? Die objektorientierte Art und Weise, wie ORM versucht, relationale Daten durchzusetzen, scheint hier ein schlechter Ansatz zu sein. Objekte sind isoliert. Wenn sie mit anderen Objekten interagieren, senden sie Nachrichten. Ihre inneren Details sollten verborgen bleiben. Relationale Daten bilden ein offenes, transparentes Diagramm. Diese beiden Welten scheinen mir völlig unvereinbar zu sein.

ORMs sind jedoch sehr verbreitet und beliebt. Funktioniert die Mehrheit der Webanwendungen mit eher isolierten Entitäten, die gut mit ORM funktionieren, oder warum ist das so? Es scheint mir, dass Sie, wenn Sie ein durchschnittlich komplexes ERD-Modell mithilfe eines ORM-Frameworks implementieren möchten, entweder auf präzisen Code oder auf Leistung verzichten müssen.

Letztendlich ist ein ORM nur eine Abstraktion, die SQL für Sie generiert und die Daten Ihren Objekten zuordnet. Speichern (tm) Sie einige 'Kesselplatte' Code.

Es gibt also nichts, was ORMs als Ganzes per Definition unbedingt schlecht können. Das Problem ist, dass Sie ORMs nicht als Ganzes verwenden, sondern eine bestimmte auswählen und diese verwenden müssen!

Ein einzelner ORM kann eine bestimmte Sache möglicherweise nicht sehr gut machen. Gespeicherte Prozesse, dynamisches SQL, berechnete Felder, komplizierte Verknüpfungen usw. können problematische Bereiche sein.

Ein subtileres Problem besteht darin, dass ein ORM, wenn er versucht, all diese Szenarien generisch zu behandeln, größer und komplizierter wird.

Wenn Sie eine große oder komplizierte Anwendung haben, ist es wahrscheinlich, dass Sie irgendwann auf ein Problem mit dem von Ihnen ausgewählten ORM stoßen. Es ist daher sinnvoll, dies im Voraus zu planen und sicherzustellen, dass Sie das ORM hinter einem Repository verstecken. Auf diese Weise können Sie es gegen eine Alternative austauschen oder bei Bedarf auf handcodiertes SQL zurückgreifen.

Sind ORMs einfach ein schlechtes Werkzeug zum Erstellen komplexer DB-Strukturen mit vielen Assoziationen?

Nein. Ruby on Rails verwendet beispielsweise ActiveRecord, das Assoziationen verarbeitet. Im Beispiel hier: /programming/5109893/rails-how-do-self-referential-has-many-models-work wird die baumartige Struktur mit 2 Codezeilen ausgeführt.

Daher würde ich argumentieren, dass es einfacher ist, als zu versuchen, Ihre eigenen SQL-Abfragen zu rollen.

Funktioniert die Mehrheit der Webanwendungen mit eher isolierten Entitäten, die gut mit ORM funktionieren, oder warum ist das so?

Wahrscheinlich nicht, aber das ist nur eine Vermutung. Die ORMs existieren in einem Ökosystem, in dem sie gedeihen, was darauf hindeutet, dass sie verwendet werden. Ich habe ORMs für Systeme mit über 20 zugehörigen Modellen verwendet und fand sie in Ordnung. Ich habe die Objekte nie gezwungen, nur mit Nachrichtenübermittlung isoliert zu werden.

Zusammenfassend lässt sich sagen, dass es bei der Erstellung "komplexer" ERD-Modelle kein Tool gibt, das diese einfach macht. Nur Werkzeuge, mit denen sie funktionieren.

Wie in mindestens einer anderen Antwort hier erwähnt, sind nicht alle ORMs gleich. Einige ORMs machen sehr wichtige Annahmen darüber, wie die Datenbank strukturiert sein sollte. Das Werkzeug sollte eine gewisse Unterstützung für das Verlassen dieses Modells bieten. Je mehr Sie sich jedoch von diesem Modell entfernen, desto weniger Wert hat das ORM. Wenn Sie mit einem dominanteren ORM-Tool arbeiten, haben Sie eine viel bessere Erfahrung, wenn Sie die Datenbank anhand ihrer impliziten Annahmen entwerfen.

Ich habe nie wirklich verstanden, warum ORMs von vielen Entwicklern und Architekten als wesentlich angesehen werden. Dies kann auf die Tatsache zurückzuführen sein, dass ich fast nie eine Green-Field-Datenbank hatte, mit der ich arbeiten konnte, und dass der Zeit- und Arbeitsaufwand für die Durchführung der ORM-Zuordnung weitaus mehr Arbeit war als das Schreiben von SQL. Entweder war das Mapping einfach (und auch das SQL) oder es war kompliziert und ich brauchte sowieso SQL (oder ähnliches). Die in ORM enthaltene Transaktionsunterstützung war meiner Erfahrung nach eher eine Quelle von Fehlern und Problemen als eine Hilfe.

Ihr Kilometerstand kann variieren, aber ich bin zu der Überzeugung gelangt, dass es besser ist, die Datenbankpersistenz als einen speziellen Fall der Datenserialisierung zu betrachten. Und genau wie ich denke, dass es keinen Sinn macht zu glauben, dass Sie ein Objekt über das Kabel "senden" können, halte ich es nicht für sinnvoll, daran zu denken, Objekte in eine Datenbank zu schreiben. Ich denke sogar, dass es völlig gültig ist, mehrere Objektdarstellungen derselben Daten für unterschiedliche Anforderungen zu haben. Das Zuordnen von Objekten zu Tabellen und umgekehrt ist zu einem Selbstzweck geworden, im Gegensatz zu einer Lösung eines Problems. Ich bin nicht davon überzeugt, dass die meisten Leute, die diese Tools verwenden, sogar einen klaren Grund haben, dies zu tun. Es ist ein Standard geworden.