bghosting

Du könntest dir die Spezifikationen des JCR anschauen (Java Content Repository). Eine PHP-Umsetzung gibt es dazu im Flow3-Projekt (dem neuen Typo3 Stream).

Im Grunde macht es bei Typo3 genau das: Vereinfacht dargestellt markierst du Objekte für die Datenbank. Sie werden dann mit ihren Attributen gespeichert und können später wieder geladen werden. Das, was dabei recht interessant ist. Abfragen werden über eine allgemeine Schnittstelle abgehandelt. Das sieht dann beispielsweise so aus:
Als Anmerkung: Das, was im klassischen Sinne eine Datenbanktabelle ist, stellt das $repositoy dar. Sprich: Das $repository weiß demnach, welche Tabelle es abfragen muss.

Just my 2 cents

__________________
Kostenloser Qualitäts-Webspace mit Projekt-Unterstützung

Mister Ad

nikosch

Leg doch lieber geschlossene Domainobjekte an und programmiere ggf. DAOs für spezifische Datenbanken nach. IMHO verspielst Du sonst jede Menge DB-spezifische Optimierungen. Der kleinste gemeinsame Nenner bietet sonst zwar austauschbare Zugriffsobjekte, die dafür aber schweinelangsam sind.

__________________
--
One pixel is still too big. Please make it smaller. ASAP.

Initiative Mittelstand.
Die wichtigste Gestaltungsregel im Screendesign ist Pi mal Daumen des Arbeitgebers.
--

xm22

Aber doch nicht bei Standardabfragen.

Mit den DAOs das ist ja in der Tat ganz hübsch, aber irgendwann kommt immer der Punkt, an dem man der entsprechenden API wieder Funktionen hinzufügen muss, weil die vorhandenen eine bstimmte Anforderung nicht erfüllen.

In meinen Augen ist ein Mix aus fixen Abfragen und dem oben gezeigten, generischen Ansatz der beste Weg.

nikosch

Standardabfragen können auch schnell sehr komplex werden. Wenn man dann nicht spezielle Gegebenheiten der einzelnen Systeme nutzt, verspielt man eine Menge Potential.

__________________
--
One pixel is still too big. Please make it smaller. ASAP.

Initiative Mittelstand.
Die wichtigste Gestaltungsregel im Screendesign ist Pi mal Daumen des Arbeitgebers.
--

mepeisen

Ab einer gewissen Größe ist der DB-Optimizer überfordert. Nicht weil er nicht zu optimieren wüsste sondern weil er für die Optimierung länger bräuchte als für die potentielle Abfrage und sie deswegen unterlässt. Anders ausgedrückt: Ab einer gewissen Komplexität ist es eventuell sinnvoller, die Datenbankabfrage in einzelne Abfragen zu spalten und diese mittels Anwendungslogik zusammenzusetzen. Dann hat man gleich auch die Chance, frühzeitig Datenkonstellationen zu erkennen, wo die weiteren Abfragen nicht mehr ausgeführt werden müssen, weil beispielsweise bereits die erste Menge leer ist.
Klar ist das bei DAOs ein zweischneidiges Schwert. Aber genauso zweischneidig ist es, die komplexeste Logik durch eine Methode und einen SQL immer abdecken zu wollen.
Eine pauschale Antwort gibt es aber nicht, denn es kommt immer auf den konkreten Anwendungsfall und den Daten/Datenmengen an, ob ein DAO mit vielen atomaren Funktionen und SQLs vorteilhaft ist oder ob man eine komplexe Methode und ein komplexes SQL vorziehen sollte.

__________________
Entwickler aus Leidenschaft und ein Zahnrad in einem der größten Java-Projekte der Welt.

Dark Guardian

Ich hab mal mit einem Klassendiagramm angefangen um etwas mehr Überblick zu bekommen.



Selbstverständlich noch lange nicht vollständig. Für Fehler im Diagramm entschuldige ich mich schon einmal im vorraus. Haben das im erstem Ausbildungsjahr nur grob behandelt und bisher hatte ich noch nicht die Muße mich weiter mit UML zu beschäftigen.

Im Prinzip soll das ganze so ablaufen:

Es wird ein DBQuery erzeugt, in diesem werden mit Hilfe der anderen Klassen die Daten für den SQL-Befehl zusammengetragen. Das DBQuery Objekt wird an ein Objekt mit dem Interface IDatabaseDriver übergeben. Der Driver hat nun die Aufgabe aus den Daten die in den Objekten stecken einen SQL-Query zu bauen der in (seinem) DBMS ausgeführt werden kann und alle angeforderten Features unterstützt.

Z.B. setz man im DBQuery Objekt $queryType auf SELECT, gibt eine Reihe von DBColumn Objekten an sowie ein DBTable Objekt. Hierraus sollte der "Datenbanktreiber", entsprechend dem Syntax des DBMS einen "SELECT DBColumn1, DBColumn2... FROM DBTable" zusammenbauen können.

So gesehen ist es die Aufgabe des Drivers die Befehle auszuführen und vom OO Format in das Datenbankformat umzuwandeln und umgekehrt. Die Anwendung soll nur mit den Objekten arbeiten müssen um Änderungen an der Datenbank vorzunehmen.

Ein anderes Beispiel wäre ein ALTER TABLE Befehl in dem eine Spalte hinzugefügt werden soll. Ich möchte nur ein DBColumn Objekt anlegen, per addColumn()-Methode eines DBTable Objektes diesem die Spalte übergeben und mehr nicht. Das DBTable Objekt erzeugt das entsprechende DBQuery Objekt, der Driver übersetzt, führt aus, und gibt ggf. Antwort ob alles geklappt hat in Form eines DBResult Objektes.

Um zu viel Overhead zu vermeiden lassen sich Objekte von DBColumn u.Ä. welche nicht alltägliche Informationen enthalten durch einen Parameter ohne diese instanzieren. Ich muss jedenfalls nicht in jedem Query wissen ob eine Spalte ein Primary Key ist oder nicht, diese Informationen aber jedes Mal bei der Instanzierung automatisch abzufragen ist denke ich zu viel des Guten.

... was haltet ihr davon, wo seht ihr Denkfehler oder schon "früh" (sollte ich das tatsächlich so umsetzen wollen) Probleme auftauchen?

Edit: Ich hab mir auch mal Doctrine angeschaut. Das ist für meine Pläne schon etwas oversized.

__________________
Möglicherweise kommt zu "Menschen lügen" auch "Menschen bauen Mist".

xm22

Was ich auf Anhieb sehe, ist eine rekursive Komposition von DBRow und DBTable. So was halte ich nicht für gut, weil die sich gegenseitig bedingen.

mepeisen

Table zu column ist bei dir eine n:m Beziehung. In relationalen Datenbanken ist das aber immer 1:n (also die Spalte gehört immer eindeutig zur Tabelle). Gleiches gilt für deine Beziehung zwischen Tabelle und Datenbank.

Dein Aufbau von DBQuery ist etwas fragwürdig. Er ist nicht falsch und kann auch durchaus für deine Sachen ausreichen, hat jedoch einige Einschränkungen. So sind bei dir keine Subselects möglich. Wie auch immer ist das aber eh etwas schwierig abzubilden

Nur Interesse halber: Wieso kennt die Datenbank die Queries?

@xm22: Wieso ist das ein Problem? Eine Beziehung zwischen zwei Entitäten lässt sich immer in beide Richtungen abbilden. Und nichts anderes hat er gemacht. Im übrigen ist eine Komposition immer ein ausgefülltes Rechteck. Er hat eine Aggregation gemacht.
Richtig wäre zwar in der Tat, dass eine Komposition von Table zur Column gäbe und keine Aggregation, da die Table das Vaterobjekt der Column ist. Da PHP jedoch Kompositionen nicht nativ unterstützt, ist es lediglich eine Geschmackssache, wie man es in UML darstellt.

__________________
Entwickler aus Leidenschaft und ein Zahnrad in einem der größten Java-Projekte der Welt.

Dark Guardian

Zu den Kompositionen und Aggregationen:

Mittlerweile denke ich dass das DBTable Objekt innerhalb der DBRow nicht unbedingt gebraucht wird. Mir ist jedenfalls beim Erstellen von einigen Verwendungszwecken kein Fall aufgefallen wo ich es benötigen würde.

Dem Konzept der relationalen Datenbanken anch stimmt es das die Abbildungen von DBTable zu Database 1:n wäre. Ebenso wie DBColumn zu DBTable. Bei der Erstellung des Diagramms hatte ich jedoch folgendes Muster im Kopf:

Was ist wenn ich eine komplette Tabelle in mehrere Datenbanken kopieren möchte? Dann erzeuge ich ein DBTable Objekte und lasse dieses alle Daten zu Spalten und alle Zeilen auslesen und füge dieses in ein anderes Database Objekt ein. Die Quelltabelle gehörte ja bereits zu einer Datenbank. Ich hätte nun also 2 Datenbanken, in denen ich die gleiche Tabelle besitze welche nur durch ein DBTable Objekt repräsentiert werden. In diesem Fall wäre das Database-Objekt innerhalb von DBTable jedoch nutzlos.

Dies werde ich dadurch abändern das Methode wie Database->addTable() die neu hinzugefügte Tabelle als DBTable zurückliefern, oder die als Parameter übergebene Tabelle, je nachdem ob die Tabelle welche übergeben wurde schon zu einer Datenbank gehört oder nicht.

Aus dem letzten erwähnten Punkt heraus habe ich auch Aggregationen anstatt Kompositionen gewählt. Wenn ich eine neue Tabelle anlege, erzeuge ich ein DBTable Objekt und füge dieses einer Datenbank hinzu. Die Tabelle ist zwar Teil einer Datenbank, das Objekt welches sie abbildet kann aber auch ohne eine Datenbank existieren bis es zu einer oder mehreren Datenbanken hinzugefügt wird.

Ein kleines Beispiel um das zu verdeutlichen:

Die Objekte können also erzeugt werden ohne das sie zu einem Vaterobjekt vorher zugeordnet werden müssen. Soweit es mir beigebracht wurde schließt dies Kompositionen aus.

Zu dem Query Objekt:

Es fehlt sowieso noch ORDER BY, GROUP BY, HAVING, USING etc. Bei den SubSelects weiss ich auch noch nicht so recht weiter.

Bei der Where-Klausel im DBWhere Objekt ist das ja relativ leicht. Als Tabellenspezifikation schon schwieriger weil ich nicht weiss wo ich den Alias unterbringen soll. Ich bin am Überlegen dem DBTable Objekt die Fähigkeit zu geben durch einen Select-Query eine Struktur annehmen zu können und nicht durch eine Anzahl von DBColumn Objekten.

So wäre folgendes Beispiel möglich:

Nun könnte ich mit $table so weiter verfahren das ich diese als Tabellenobjekt in DBQuery angebe oder auch in einem DBJoin verwende. Das MySQLDatabaseDriver Objekt kann somit darauf reagieren ob die Tabelle physikalisch existiert oder durch einen Select erzeugt wurde und entsüprechend den Select in den Query integrieren anstatt eifnahc nur den Tabellennamen zu verwenden (dieser ist dann im Falle eines Selects der Alias für die Tabelle).

Bei INSERT Befehlen verhält es sich ähnlich. Anstelle eines Liste von DBColumns wird ein DBQuery, welcher den Select repräsentiert angegeben. Bei UPDATE Befehlen im DBSet Objekt genauso. Dies konnte ich im Klassendiagramm leider nicht festhalten da es in dem Programm welche sich benutze anscheinend nicht möglich ist für eione Membervariable mehrere mögliche Datentypen anzugeben.

Nun zu der Frage warum die Datenbank die Queries kennt:

Die Datenbank kennt als einziges das IDatabaseDriver Objekt. Ich weiss noch nicht ob ich die DBQuery Objekte immer durchreichen will oder ob ich sie direkt bei der Datenbank registriere. Im Falle des letzteren würde die Datenbank die Queries kennen.

Außerdem dachte ich mir das es von Vorteil sein könnte wenn die DBQueruie Objekte die intern von den Klassen genutzt werden nicht bei jeder Verwendung in den Methoden als lokale Variablen neu erzeugt werden sondern zentral registriert werden. Das Database Objekt ist hierfür warscheinlich nicht der beste Platz, aber der Vermerk ist mir erst einmal lieber als diese Option hinterher zu vergessen.

__________________
Möglicherweise kommt zu "Menschen lügen" auch "Menschen bauen Mist".

mepeisen

gleich !== selbe

Du hast trotz allem aber immer eine Kopie. Wenn du in der Kopie eine Spalte hinzufügst nachträglich, ist sie im Original nicht hinzugefügt. Wenn du eine n:m-Beziehung hast und eine Tabellenkopie so umsetzt, dass dasselbe Objekt wiederverwendet wird, stimmt das nicht mehr.

Wenn du stattdessen zwei Tabellen haben willst, die wirklich dieselben sind und mit gleichen Inhalten in zwei Datenbanken auftauchen, dann nutze beispielsweise das Proxy-Pattern. Deine Implementierung wird jedoch ungleich etwas schwieriger, weil viele Datenbanksysteme solche Proxy-Tabellen oder wie mans nennen will (also Tabellen, die zeitgleich identisch in zwei Datenbanken verfügbar sind) erst einmal nicht unterstützen. Einige wenige können das.
Eine Alternative dazu wären Views.

__________________
Entwickler aus Leidenschaft und ein Zahnrad in einem der größten Java-Projekte der Welt.