MariaDB mit ORM oder besser ohne

[Joa]

Hallo,

ich hätte eine dringende Frage.
Ich lasse gerade 2 Informatiker zwei verschiedene Projekte umsetzen.
Beide Projekte greifen auf die gleiche MariaDB zu.

Der eine Informatiker möchte gerne ORM einsetzen, der andere ist dagegen.
Ich möchte dass eine einheitliche Vorgehensweise bei beiden Projekten umgesetzt wird.

Aussage Informatiker 1:

Letztlich bietet mir ein ORM die Möglichkeit die Verarbeitung und Abbildung der Daten auf die Datenbank entsprechend zu vereinfachen ohne eben viele Dinge von Hand erledigen zu müssen. Wenn es gewünscht ist, werde ich entsprechend darauf verzichten, ich möchte nur gerne anmerken, dass ORM nicht per se schlechtere Performance liefert, sondern es da zum Teil gravierende Unterschiede zwischen den einzelnen ORM-Implementierungen gibt und es auch mit ORM möglich ist in gewissem Rahmen Performanceoptimierungen vorzunehmen.
Ein gewisser Overhead besteht bei allen Bibliotheken, die man einsetzt um das "Rad" nicht neu erfinden zu müssen.

Aussage Informatiker 2

ganz grob gesagt macht man sich unter -Performance Einbusen Vorteile einer ordentlich relationalen Datenbank kaputt da diese nicht ausgespielt werden können. Auch schränkt man sich bei der Nutzung von DB seitigen Funktionen ein. - Dies macht sich um so mehr bemerkbar um so komplexer und/oder zielgerichteter die Abfragen werden. - Bei einfachen hol mir alle Felder zu Datensatz X aus Tabelle Y macht der Einsatz kaum etwas aus. Anders sieht es idR. aus wenn man bspw. nur gezielte Felder mit vielen joins und unter Nutzung DB seitiger Funktionen abfrägt und hier sehe ich dann Nachteile insb. im Bereich der Intranetanwendung. Dazu kommt eben der Unnötige "Overhead" in der Applikation selbst.

Was meint Ihr ORM Ja oder Nein.
Würde mich über Antworten (toll wäre mit Begründung) sehr freuen

Viele Grüße

[nameless97]

Hallo,

ich hätte eine dringende Frage.

Die hat hier jeder

Ich würde behaupten, es kommt drauf an, was es überhaupt für eine Applikation ist und wie die meisten Queries aufgebaut sind.
Ich persönlich würde auch zum ORM greifen, wenn man aber aufgrund sehr komplexer Queries eh ständig einen DBAL oder was auch immer benutzen müsste, dann macht das mE. auch wenig Sinn.

[ChristianK]

Ich persönlich kenne genug Gründe, wieso man auf ein ORM verzichten soll. Unnötiger Overhead, unnötig erhöhte Anzahl Datenbankabfragen und immense Verluste an SQL-Wissen sind nur der Anfang.

Der Herr 1 mag recht haben, der Overhead ist meiner Meinung nach jedoch nicht das Entscheidende. Viel schlimmer finde ich, dass man versucht, relationelle Daten in Objekte zu packen - und das geht nun mal einfach nicht.

[rkr]

Ich sehe das ähnlich wie ChristianK. Zwar will ich anmerken, dass "Performance" kein guter Grund ist ein wesentlich besseres Softwaredesign zu verkomplizieren - im Falle von ORM sehe ich persönlich viel mehr Vorteile, wenn man näher an SQL arbeitet. Es ist meiner bescheidenden Ansicht nach wirklich etwas dran, dass OOP und relationale Daten wenig zueinander passen. Ich könnte das auch breit ausführen, aber ich habe das Gefühl, das wäre in diesem Thread vergebens.

[Joa]

Vielen Dank für die bisherigen Antworten.
Ich hoffe es machen sich noch ein paar Forummitglieder die Mühe zu antworten.
Die meisten sprechen sich bis jetzt klar gegen ORM aus.

rkr

vielleicht wärst Du doch so freundlich und könntest doch noch ein paar Zeilen schreiben, warum Du gegen den Einsatz von ORM wärst.
Du hast recht ich kann die Antworten sicher nicht ausreichend bewerten.
Aber es gibt sicher Forummitglieder die auch sehr an der Meinung interessiert wären und ich möchte die Antworten meinen Informatikern als Diskussionsgrundlage vorlegen.

Viele Grüße

Joa

[alxy]

Ich benutze quasi immer einen ORM. Ich arbeite aber auch nicht mit so großen Datenmengen, dass ich da einen goßartigen Performanceverlust befürchte. Und da weiß ich dann die Einfachheit, Struktur und Schnelligkeit (beim Programmieren) zu schätzen.
Ich benutze übrigens Eloquent als ORM-Implementierung.

[tr0y]

ORMs schließen native SQL-Entwicklung nicht aus, du kannst mit ORMs durchaus benutzerdefinierte Queries auf Entities mappen und eine ebenso niedrige Query-Frequenz und erwünschte Performance erreichen.

[rkr]

@Joa
Es gibt tatsächlich kein allgemeingültiges Rezept, nach dem man ORMs kategorisch ein- oder ausschließen kann. Es kommt ein wenig auf den Anwendungsfall, die Daten und das ORM an.

Arbeitet man mit Applikationen, bei denen einzelne Entitäten klein, groß, oder gar dynamisch sind?
Arbeitet man mit komplexen Daten, deren Integrität durch Mittel der Datenbank sichergestellt sein muss?
Braucht man ständig spezielle Datenbankfeatures oder nutzt eine Reihe von Feldtypen, die es in der eingesetzten Sprachumgebung der Applikation so nicht gibt?

Für Daten gibt es spezielle Objekt- und Graphen-Datenbanken, sowie NoSQL-Systeme. Die gibt es, weil sich viele Anwendungsfälle schlecht auf einer relationalen Datenbank darstellen lassen, oder einen speziellen Bedarf an Performance oder Funktionsumfang haben (siehe Map/Reduce). Wenn wir also über "Daten" und "Datenbanken" sprechen, dann müssten wir auch über den Einsatzzweck dieser Daten sprechen - sowohl im Anwendungskontext, als auch bei der Skalierbarkeit, der Ausfallsicherheit oder der Zugänglichkeit.

Dann haben wir eine reiche Auswahl an ORM-Systemen. Anscheinend ist bislang mit keinem der große Wurf gelungen - alle Systeme kenne ich nicht und kann daher auch nicht sagen, welche Schwerpunkte sich da im einzelnen herausgebildet haben. Teilweise weichen die Konzepte jedoch stark voneinander ab.

Sprechen wir über n-dimendionale Daten, die bereits in einem RDBMS liegen, dann versucht ein ORM diese Daten auf Objekte der eingesetzten Sprachumgebung zu mappen. Und das so automatisch, wie machbar, möglichst ohne den Einsatz einer weiteren Sprache wie SQL und ohne speziellen Anwendungscode, der die Daten der Datenbank in die Objektwelt der Applikation überführt. Wenn man denn schon ein ORM einsetzt, dann will man auch, dass dieses Mapping möglichst viel Arbeit spart und dadurch die Objekte so formt, wie dessen Datenvorbild auch in der Datenbank liegt. Und hier kommt der eigentliche Kernpunkt: Objekte sind keine relationale Datenspeicher. Sie können Verhalten haben und verstehen das Konzept von Arrays, Referenzen, Vererbung und Kapselung. Datenbanken kennen z.T. zwar ähnliche Konzepte, beschreiben diese aber anders oder unterstützen diese Ausprägung nicht.

Es ist auch undurchsichtig, wie ORMs ihre Ziele erreichen. Teils werden Daten, die auf in einer Datenbank mit Zuhilfenahme von vielen Tabellen normalisiert abgebildet werden, mit einzelnen Abfragen zusammengebaut, die man teils vielleicht sogar mit nur einer Abfrage beziehen kann. Man hat mehr Spielmöglichkeiten, wenn man den manuellen Weg geht. Hier kommt es dann wieder auf den Anwendungsfall an. Natürlich kann sich ein ORM in einer sehr großen Applikation ohne große Probleme in jedweder Richtung einsetzen lassen, wenn die Datenstruktur des jeweiligen Anwendungsfall dies begünstigt.

Nicht selten fällt das Argument, dass Objekte durch Annotations eine Tabelle beschreiben können und so Datenbanktabellen aus Objekten erzeugt werden können, um nicht jede Schemaänderung ständig mehrfach zu machen (was man in jedem Fall muss). Das funktioniert allerdings nur beim ersten Mal. Mir ist kein ORM-System bekannt, welches Tabellenfelder, welche bereits Daten beinhalten, umbenennen können. Passt man hier nicht auf, kann das einen Datenverlust nach sich ziehen. Daher gehen die meisten Entwickler bei Datenbankänderungen über ein Migrationssystem. Einige ORM-Systeme bringen so etwas mit.

Am Anfang einer neuen Applikation fühlt sich ORM auch gut an. Man kann direkt mit Objekten arbeiten und muss nicht ständig irgendwelche Mapper von Hand schreiben, die Daten aus einem Array an Getter- oder Daten an ein Array aus Setter-Methoden eines Objekts reicht oder direkt die Daten mit den Objekteigenschaften (Properties) verbindet. Mit einer wachsenen Applikation merkt man dann aber schnell, dass man vielleicht nicht in jeder Situation auf das richtige Objektdesign gesetzt hat und Datenstrukturen datenbankseitig anpassen muss. ORM begünstigt entweder ein ungünstiges Objektdesign zugunsten eines optimalen Datenbankdesigns, oder umgekehrt - zumindest spiegelt das meine Erfahrung wieder.

Positiv ist auf jeden Fall, dass ORMs in aller Regel den Zugriff auf die Datenbank so weit abstrahieren können, dass ein späterer Wechsel auf ein anderes Datenbanksystem weniger Anpassungsaufwand erfordert - wenn überhaupt. Wenn man nahe mit den jeweilig herausstellenden Funktionen eines jeweiligen RDBMS arbeitet, dann ist auch klar, dass der Wechsel auf ein RDBMS mit abweichendem Funktionsumfang nicht ganz schmerzfrei über die Bühne gehen kann. Besonders der Wechsel von einem RDBMS auf eine NoSQL-DB.

Hat man bereits eine fertige Datenbank, dann wird ORM schnell hässlich. Wenn eine Datenbank nicht eng mit einem ORM zusammen erstellt wurde, dann kann die Integration eines ORM zu einer sehr langwierigen und fehleranfälligen Geschichte werden. Sind boolsche Felder mit einem Set/Enum (‘Y’,’N’) erstellt worden, oder mit einem Bit/Tinyint/Smallint/Bool? Oder mit einem String, wo ‘JA’ oder ‘NEIN’ steht?
Ist eine Zahl eine Ganzzahl, eine Dezimalzahl mit Vorzeichen, oder ohne? Mit fester Dezimalgenauigkeit oder ohne?
Das muss man alles auch berücksichtigen, wenn man alles zu Fuß macht, aber dann überlässt man nicht alles der Magie des ORMs.

Eigentlich geht das aus dem vorangegangenden Text schon hervor, aber man sollte nur dann Entwickler mit einem ORM an größere Systeme lassen, wenn sie in diesem Bereich Erfahrungen an kleineren Systemen mitbringen. Man kann nicht einfach daher gehen und bekannte OO-Designmuster mit einem ORM verbinden. Man muss schon wissen, was man da tut und damit wesentlich mehr Wissen mitbringen, als hätte man die gleiche Arbeit mit traditionellen Mitteln erledigt.

Noch kurz zum Abschluss: Vieles, was ich hier beschrieben habe, beruht auf eher subjektiven Erfahrungen, die ich in 15 Jahren Arbeit mit verschiedenen Datenbanksystemen gesammelt habe. Ich kann mir vorstellen, dass ein ORM-Veteran hier Konzepte vorstellen kann, die meine Aussagen stark relativieren, ggf sogar negieren können.

[mYkon]

Das funktioniert allerdings nur beim ersten Mal. Mir ist kein ORM-System bekannt, welches Tabellenfelder, welche bereits Daten beinhalten, umbenennen können.

Doctrine

Wobei bei mehreren Spalten die dann z.T. wieder gleich heissen aber der Typ geändert hat, schon komische Sachen passieren können. Aber grundsätzlich funktioniert das dort.

Die ganzen "manuell gehts besser, ORM nicht geeignet für relationale Daten" Argumente kann ich bei meinen Projekten eigentlich alle widerlegen.

Ich will OOP Programmieren, damit ich mit anderen Programmieren am selben Projekt mit definierten Schnittstellen und Aufgabenbereichen arbeiten kann. Das ist für mich nur mit einem anständigen ORM möglich.

Wenn ich Queries habe, die zu lange dauern, weil a) zuviel oder b) nicht die richtigen Daten in die Objekte geladen werden, benutze ich DQL. Wenn das noch nicht reicht, dann kann ich auch natives SQL schreiben. Wenn ich will kann ich aber auch DQL schreiben und mir Arrays anstatt Objekte zurückgeben lassen, die überhaupt nicht gemappt sind.

Ich habe gefühlt (wenn man denn "professionell" OOP programmieren will) 90% an Vorteilen gewonnen und 10% an Vorteilen ggü. z.B. Active-Record eingebüsst.

Wenn ich heutzutage nur schon ein Projekt sehe wo es ein "update-123-19.02.2010a.sql" und "update-123-19.02.2010b.sql" sehe um mir mein DB Schema auf den aktuellen Stand des PHP-Codes zu holen wird mir schlecht...

[ChristianK]

Naja, ich kann dir genug renommierte Artikel vorlegen, die deine Argumente zu genüge widerlegen. Wir könnten jedoch auch gleich darüber diskutieren, ob jetzt PHP, Java oder Perl besser ist .

[lottikarotti]

Hallöchen,

ich möchte jetzt nicht allzu tief in die Thematik einsteigen und mich auch nicht für oder gegen ORM positionieren, aber persönlich nutze ich für alle meine PHP-Projekte Doctrine. Für performance-kritische Aufgaben greife ich auf DQL oder natives SQL zurück. Ein Hauptgrund für mich ist die schnelle Umsetzung von CRUD-Anwendungen und die saubere Schnittstelle, ähnlich wie das mYkon bereits angedeutet hat. Das lässt sich sicherlich auch auf anderen Wegen erreichen, aber Doctrine ist nun mal verdammt bequem

Grundsätzlich bin ich aber der Meinung, dass Entwickler mit den Tools arbeiten sollten, die sie beherrschen, sonst stoßen sie früher oder später auf unangenehme Probleme oder gar an Grenzen.

Viele Grüße,
lotti

[mYkon]

Naja, ich kann dir genug renommierte Artikel vorlegen, die deine Argumente zu genüge widerlegen. Wir könnten jedoch auch gleich darüber diskutieren, ob jetzt PHP, Java oder Perl besser ist .

Dass ein ORM keine relationale DB abbilden kann (in der Theorie) ist mir bewusst und unterschreibe ich auch so. Das man deswegen auf ein ORM verzichten muss jedoch nicht. Das meinte ich mit: "Ich kanns aus meiner Erfahrung widerlegen".

Vorteile überwiegen für mich einfach ganz klar.

[ChristianK]

Die Vorteile des ORM sind in kleineren, einfachen Applikationen vielleicht grösser. In grösseren Applikationen bin ich der Meinung, dass das ORM zu Beginn vieles vereinfacht, mit späterem Verlauf die Dinge jedoch um einiges kompliziert macht, als mit anderen Ansätzen.

Doch wie gesagt, das ist kein objektiver Krieg, das ist wie Religion.

[nameless97]

@TE:

Deine beiden Informatiker sollten sich am besten auf den besten gemeinsamen Nenner einigen.
Wenn Informatiker 1, wie du schreibst, auch auf das ORM verzichten würde und beide mit nativem SQL umzugehen wissen, macht es vielleicht ohne ORM mehr Sinn. Aber das müssen die dann unter sich entscheiden, denn sie sind ja die, die damit arbeiten müssen

[ChristianK]

Eigentlich ist das falsch. Das hat nicht der Informatiker, sondern der zuständige Software-Architekt, der Projektleiter oder ggf. einer der Stakeholder zu entscheiden. Der Informatiker darf umsetzen (und bei etwas Glück mitdiskutieren).