Was ist das Problem?

Die meisten Webanwendungen speichern ihre Daten in relationalen Datenbanken und sind selbst objektorientiert programmiert. Während des Programmablaufs sind die Daten in Objekten gekapselt, diese serialisiert in der Datenbank zu hinterlegen wäre keine gute Idee, würde man doch die Vorteile einer relationalen Datenbank einbüßen. Ein Objekt hat einen Zustand, Verhalten und eine Identität. Eine relationale Datenbank kennt nur Relationen und dazugehörige Tupel. Das Problem, Objekte in einer relationalen Datenbank zu speichern, nennt sich “Object-relational impedance mismatch“.

Wie kann man das Problem lösen?

Helfen kann man sich mit einer (eineindeutigen) Abbildung zwischen Datenobjekten und Tabellen einer Datenbank. Ein Objekt wird auf eine Tabelle abgebildet und Attribute auf eine Spalte der Tabelle. Der Primärschlüssel eines Tupels stellt die Identität des Objekts dar. Vererbung und Referenzen auf andere Objekte  kann man dann über Fremdschlüssel lösen. Object relational Mapper sind Bibliotheken, die solche Abbildungen implementieren. Anstatt direkt auf die Datenbank zu zugreifen, kann man objektorientiert mit den Datenobjekten arbeiten, welche sich um die Interaktion mit der Datenbank kümmern. Allerdings muss man meistens Einbußen bei der Geschwindigkeit hinnehmen.

Object relational Mapper in PHP:

Die Anzahl von ORMs in PHP nimmt stetig zu. Fast jedes Application Framework ist mittlerweile mit einem ORM ausgestattet, sei es eine Eigenentwicklung oder ein fremdes ORM. Deshalb kann ich hier nur ein paar Beispiele nennen und keinen Anspruch auf Vollständigkeit erheben. Wenn ihr mir weitere Adressen in den Kommentaren schreibt, ergänze ich diese natürlich.

ORM Bibliotheken in PHP:

• cakePHP (Application Framework mit ORM)
• DB_DataObject
• Doctrine (Teil des Symfony Frameworks)
• pdoMap
• Propel (Teil des Symfony Frameworks)
• …

Fazit:

Schneller und performanter werden Anwendungen durch ORMs nicht, aber das Arbeiten mit einer Datenbank wird durch sie wesentlich vereinfacht.