Bei Datenbankverbindungen in PHP gehen die Meinungen der Entwickler schnell auseinander. Jeder verwendet die schnellste Lösung oder schreibt schnell eine Klasse welche die wichtigsten Funktionen übernimmt. Mittlerweile stehen dem Entwickler ja drei native Schnittstellen zur Verfügung: mysql, mysqli und PDO – wobei jede Vor- und Nachteile aufweist. Und es gibt eine Reihe von Abstraktionsschichten welche das Auslesen und Bearbeiten von Datensätzen erleichtern sollen wie z.B. ADODB, Creole/Jargon oder die Tools um MDB2 auf PEAR. Allerdings deckt keines dieser Werkzeuge den gesamten Bereich richtig ab. Schemadateien müssen von Hand erzeugt werden, Mapper von PHP Objekten sind umständlich zu konfigurieren, initialer Datenimport muss von Hand erledigt werden und komplizierte Abfrageteile werden dann doch wieder in SQL realisiert.
Seit 2006 wird an dem ORM Tool Doctrine geschraubt welches seit September in einer stabilen major release vorliegt. Doctrine orientiert sich an Hibernate aus der Javawelt und an den Active Record Pattern von Ruby on Rails. Das tolle ist: Man schreibt fast (!) keine einzige Zeile SQL mehr.
Die Relationen aus der Datenbank werden auf verschiedene Arten in PHP Objekte übersetzt. Man kann entweder gleich PHP Klassen schreiben (Aus denen dann später auch das Datenbankmodell erzeugt werden kann), lässt sich die Klassen aus einer bestehenden Datenbank erzeugen oder schreibt das Modell in einer deskriptiven, Doctrine eigenen Sprache welche auf YAML basiert. Es ist auch möglich verschiedene Datenbanken in einem logischen Modell zu Verbinden. Selbst solche Strukturen verhalten sich in PHP völlig transparent.
Doctrine an sich besteht aus einer Reihe von Objekten wie Connections, Tables, Collections, Records, Queries. Letztere können durch eine eigene, an SQL angelehnte Sprache, abgefragt werden (Anlehnung an HQL von Hibernate: DQL). Alle diese Objekte folgen speziefischen Entwurfsmustern wie Singletons, Prototypes oder EventListeners und können dadurch einfach erweiter werden.
Für kleinere Projekte schießt man damit sicherlich mit Kanonen auf Spatzen, auch benötigt man etwas Einarbeitszeit um den Baukasten zu verstehen. PHP geht damit aber insgesamt einen großen Schritt in Richtung Enterprisesoftware. Orientiert sich ein geplantes Projekt in diese Richtung ist Doctrine sicherlich nicht verkehrt und nimmt für die Zukunft eine Menge Arbeit ab: Cheatsheet von Doctrine.
Hi Marius,
hat man da auch Einfluss wie die Keys verwendet werden? Mein „Problem“ mit solchen Abstractionlayern ist, dass man Queries nicht wirklich gut an Hand vom Execution Plan optimieren kann. Die Optimierung endet dann meistens als stored procedure in der Datenbank. Also verlagert man die Queries „nur“ weg von PHP hin ins SQL. Das hat zwar auch seine Vorteile, aber machts auch wiederum nicht einfacher.
Gruß Gerd
Wenn du Indizes meinst würde ich ja sagen. Man kann es natürlich nicht so granular einschränken wie mit SQL selbst, aber es wird ja immer der beste Key verwendet der da ist. Man muss natürlich bei der Verwendung von solchen Schichten immer aufpassen, dass man nur das holt was man braucht und nicht gleich den kompletten Objektbaum. Was du genau willst kannst du mit Doctrine genau einschränken und auch auf die Joins hat man einen sensiblen Zugriff.
LG Marius.
😉 der beste Key ist nicht immer der optimalste… Wichtig ist halt, dass man den Execution Plan zu den Queries bekommen kann und die Queries entsprechend einstellen kann. Manchmal haben kleine Dinge große Wirkung. Erinnerst Dich noch an die Auswirkung von Klammer beim mysql Query 😉
GErd