ORM bedeutet Object-Relational-Mapping.
Also geht es darum, Strukturen, die nach dem objektorientierten Paradigma erstellt wurden, in Relationale Strukturen zu mappen, oder sagen wir besser zu pressen.
Daten, und damit Datenstrukturen, leben sehr lang!
Vertragsdaten bis zu 30 Jahre nach Vertragende und es gibt Verträge, die 100 oder mehr Jahre bestehen können.
Konstruktionsunterlagen, vor 50 Jahren ja noch meist auf Papier, heute in Datenstrukturen, müssen so lange lesbar sein, wie das Gerät im Einsatz und damit gewartet werden muss. Der US-Bomber B52 von Anfang der 1950ziger Jahre soll bis 2050 fliegen, ein Tunnel, der heute gebaut wird, wird hoffentlich über 200 Jahre halten.
Der Objektorientierte Ansatz in der Informatik lässt sich zwar bis in die 1960ziger Jahre zurückverfolgen, aber eine kommerzielle Bedeutung hat er erst seit Anfang der 1990ziger Jahre. Es gibt einige andere Paradigmen in der Informatik, regelmäßig kommen neue Paradigmen hinzu, und ob in 20, 50 oder 100 Jahren der OO Ansatz immer noch als „das Beste“ gilt?
Das Relationale Modell ist sehr simpel, im Sinn von „genial simpel“. Es lässt sich gut auf Strukturen, die bei den verschiedenen Paradigmen genutzt werden, abbilden. Es lässt sich auch gut verstehen, aus den Strukturen der Tabellen, deren Indizes, deren Relationen kann der geübte Entwickler den Sinn einer Anwendung erkennen.
Objektmodelle sind meist komplexer, denn sie sollen schnell aus der komplexen Realität hergeleitet werden. Ein OO-Entwickler, der die entsprechende Programmiersprache beherrscht, kann auch den Sinn einer Anwendung erkennen, aber versteht ein Java-Programmierer ein Modell in Smalltalk?
Geht es um einen zeitlich überschaubare Anwendung, zum Beispiel die Verwaltung eines Preisausschreibens, kennt der Entwickler Java, hat aber keine Ahnung von Datenbanken, steht die Time-To-Market im Vordergrund, ist der ORM Ansatz sicher gut, auch wenn es für solche Dinge sicher noch bessere Programmiermodell gibt, zum Beispiel „Ruby On Rails“.
Bei dem ORM Ansatz wird zuerst das Objekt-Modell erstellt und sicher auch im Lauf der Zeit weiterentwickelt. Hieraus werden dann regelmässig die Relationale Strukturen und die Zugriffsmodule generiert. Am Ende steht dann ein Relationales Modell, das nicht nur die Komplexität des Objekt-Modells, sondern auch dessen Entwicklungshistorie enthält.
Wenn dann, nach vielen Jahren, in denen die Anwendung stabil und ohne Wartungsaufwand lief, also kein spezielles Know-How für diese Anwendung mehr verfügbar ist, eine grössere Anpassung, vielleicht in einer neuen Programmiersprache in dem dann „besten“ Programmier-Paradigma, notwendig wird, versteht der Entwickler nur „Bahnhof“.
Dabei interessieren ihn wie auch die Anwender oder das Management nicht das alte Programm, interessant sind nur die Dateninhalt und wie sie weiter abgefragt und gepflegt werden können.
Auch wenn es etwas mehr Arbeit ist, scheint es mir sinnvoll, zuerst ein für die Anwendung angemessenes Datenbank Design zu entwickeln, dieses dann mit Verstand und nicht mittels Automatik in ein Objekt-Modell zu transferieren und die Zugriffsschicht zu schreiben.
Damit sind wir bei ROM, aber die Abkürzung ist schon besetzt.