nicht angemeldet
Hi!
Die Problematik bezüglich Objekten und RDBMS waren mir von vornherein klar. Meine Sicht auf die Dinge ist auch anders als du beschreibst. Bei deiner Beschreibung stehen die Objekte im vordergrund, welche man versucht auf in eine Datenbank zu pressen. Ich hingegen möchte die Tabellen der Datenbank in Objecte pressen :D.
Man muss ja nicht unbedingt Gewalt anwenden. Es finden sich garantiert auch Lösungen, die ohne zu pressen geschmeidig miteinander werkeln. So wie du an die Sache rangehst, die Struktur der Tabellen abzubilden, empfiehlt es sich eher für Datenbankverwaltungswerkzeuge als für Anwendungen, die die Datenbank lediglich als Speicher für Daten verwenden wollen.
Für deinen Ansatz gibt es ja diverse Frameworks. Die erkaufen sich aber die Effektivität, welche man beim programmieren hat durch eine schlechtere Datenbank-Anbindung (;)).
Die Frameworks können nur mehr oder weniger eine allgemeine Lösung bieten, weswegen sie auf allgemeinem Weg versuchen müssen, das Problem zu lösen. Und das muss ja auch zu einem großen Prozentsatz reichen, sonst hätte das Prinzip nicht so eine große Verbreitung/Akzeptanz. Einige bieten auch die Möglichkeit, Views oder Stored Procedures anzusprechen, und damit kommt man der Individualität schon einen großen Schritt näher. Du musst ja aber keines dieser Frameworks einsetzen.
Eine einfache Möglichkeit wäre, die starre Verbindung zwischen Tabelle, Abfrage und Klassen zu lösen. Dann kannst du Abfragen nach Bedarf erstellen, beliebig viele Tabellen dafür verwenden und füllst deine Objekte nach Bedarf und vor allem passend zu den Anforderungen.
Dass kann ich mir im Moment nicht vorstellen...
Nicht unbedingt mit einem allgemein konzipierten Framework. Es wäre ja auch möglich, dass du nur eine allgemeine Datenbank-Zugriffsschicht nimmst, die grundlegende RUDI/CRUD-Operationen ausführen kann. Die nächste Schicht hat als AUfgabe, zwischen deinen Objekten und der Persistierung zu vermitteln. Und die kannst du individuell lösen. Sprich: für jedes individuelle Problem erstellst du ein individuelles Statement und bekommst die Daten genauso, wie du es für den Moment benötigst. Wenn sich mal was an deiner Tabellenstruktur ändert, musst du theoretisch nur dieses eine Statement umschreiben, und alles andere läuft weiter. Praktisch wird es wohl eher so sein, dass diese Änderung aufgrund fachlicher Anforderungen erfolgen soll und man diese auch im restlichen Programm berücksichtigen muss.
Wenn du allerdings mit deinem Model mal was an einer Tabelle änderst, kommst du im Prinzip gar nicht daran vorbei, alle Verwendungen im Programm ebenfalls anzupassen.
Und wenn du mal schauen willst, wie andere Frameworks das lösen, such nach Eager Loading und Lazy Loading. Sowas lässt sich prinzipiell auch mit PHP und etwas Magie bewerkstelligen.
...aber hier steckt eventuell die Lösung.
Im Umfeld dieser beiden Muster wirst du auch darauf treffen, wie im Allgemeinen die Beziehung zwischen Daten und Persistierung aufgebaut ist.
Lo!