Konzept einer Datenbankabstraktion - Seite 3

Dark Guardian · 23.01.2010, 11:56

Zitat:

Zitat von mepeisen

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.

Das Thema 2 Tabellen in mehreren Datenbanken habe ich erst einmal beseite geschoben da ich noch andere Schwierigkeiten entdeckt habe, welche eine ähnliche Problematik haben.

Und zwar geht es darum wenn eine Datenbank an verschiedenen Stellen der Anwendung genutzt werden sollen.

PHP-Code:

  $db1 = DatabaseFactory::getDatabse('database');
$db2 = DatabaseFactory::getDatabse('database');

Dann hätte ich zwei, voneinander unabhängige, Datenbankobjekte welche aber die gleiche Datenbank repräsentieren. Wenn der Objektinhalt synchron zum Datenbankinhalt gehalten werden soll, haut das nicht hin.

Wenn ich in $db1 eine Tabelle hinzufüge und danach in $db2 die Tabellen abrufe dann bekomme ich, ohne vorher einen neuen SQL Befehl abzusetzen, falsche Resultate.

Die Frage die ich mir jetzt stelle ist wie problematisch das wirklich ist.
Wenn ich den Inhalt synchron halte habe ich überall in der Anwendung mit jedem Datenbankobjekt immer den gleichen Datenstand und kann jederzeit auf die Tabellen zugreifen ohne vorher das Objekt aktualisieren zu müssen.

Z.b.

PHP-Code:

  $db1 = DatabaseFactory::getDatabse('database');

$table = new DBTable('test');
$db1->addTable($table);  

//An anderer Stelle in der Anwendung z.B. in einem anderem Controller
$db2 = DatabaseFactory::getDatabse('database');

$table = $db2->getTable('test');

Der letzte Befehl ist dabei das Problem. Ich habe nun folgende Möglichkeiten das Objekt reagieren zu lassen:

- das Objekt kennt die Tabelle nicht und es wird ein Fehler ausgegeben
- das Objekt stellt eine Anfrage an die DB ob es die Tabelle gibt und aktualisiert sich selbstständig
- das Objekt setzt einfach immer einen Describe-Befehl ab und reagiert auf die SQL Rückgabe entsprechend

Die erste Variante ist unglücklich weil es die Tabelle ja tatsächlich gibt. Variante 2 und 3 erzeugen nicht nötigen Overhead da die Tabelle der Applikation ja bereits bekannt ist.

Das Proxy-Pattern ist hier durchaus eine Lösung. Die Factory hält die "echten" Objekte und leitet nur Proxies weiter welche das "echte" Objekt kennen.

Das Problem: Wenn ich immer nur DatabaseProxy-Objekte zurück gebe und nicht Database kann trotzdem ein anderer Entwickler auf die Idee kommen via "new Database" auf eine Datenbank zugreifen zu wollen was zu Schwierigkeiten führen wird. Hier fehlt PHP das Schlüsselwort "friend" um den Konstruktor nur von bestimmten Klassen aufrufbar zu machen. -_-°

Wie gehe ich damit um? Pfeif ich auf Mögliche Dummheit anderer Entwickler oder sollte ich mir besser etwas einfallen lassen um das zu verhindern? Das gleiche Problem stellt sich im übrigen auch bei DBTable, DBColumn und DBRow wenn diese sich ändern.

Wenn man jedoch anders herum denkt, kann es auch durchaus vorkommen das bewusst 2 Objekte ungleichen Inhalt haben sollen. Zum Beispiel wenn ich ein DBRow Objekt habe um Daten auszulesen, einen Klon davon um die Daten zu ändern, die Originaldaten aber zur weiteren 'Verarbeitung noch benötige. Wenn sich dnan beide DBRow Objekte automatisch synchronisieren ist das wieder schlecht.

Chriz · 30.01.2010, 00:36

Darf ich mal was einschieben?

Dein Konzept ist, so wie ichs beim Ueberfliegen aufgefasst habe, konzeptlos

Was willst du denn eigentlich machen? ORMapping, TableGateway, eine Datenbankabstraktion, eine Datenbankzugriffsabstraktion? Entscheid dich mal!

Bei allem was du machst, abstrahier in Stufen. Kein Entwickler mag es, wenn das Absenden eines manuellen Queries zum Hoelleninferno wird, weil 10 Abstraktionsschichten glauben, sie wuessten was du eigentlich willst.
Wenn du wirklich mehrere Datenbanken transparent ansprechen moechtest, versuch Queries als Objekte abzulegen. Zend_Db_Select hat sich da als sehr hilfreich erwiesen, wir nutzens fuer MySQL und Oracle (PDO jeweils). Solangs nicht sehr komplex wird, ist damit alles moeglich. Falls doch, hast du Adapter, die du entsprechend anpassen kannst.

Also resete nochmal deine ganzen Plaene von DBTable usw. Ich halte das fuer Murgs. Spaetestens bei nem Join flitzt dir da ein unueberlegtes Konzept gegen die Wand.

Synchronisieren wuerde ich komplett streichen. Was auch immer du damit bezwecken wolltest.

Dark Guardian · 30.01.2010, 14:31

Zitat:

Dein Konzept ist, so wie ichs beim Ueberfliegen aufgefasst habe, konzeptlos Was willst du denn eigentlich machen? ORMapping, TableGateway, eine Datenbankabstraktion, eine Datenbankzugriffsabstraktion? Entscheid dich mal!

Im Prinzip soll das ein OR-Mapper werden welcher mit verschiedenen DBMS arbeiten kann.

Zitat:

Bei allem was du machst, abstrahier in Stufen. Kein Entwickler mag es, wenn das Absenden eines manuellen Queries zum Hoelleninferno wird, weil 10 Abstraktionsschichten glauben, sie wuessten was du eigentlich willst.

Das ist ja nicht der Fall. Der gegenwärtige Plan sieht so aus das ein DBQuery Objekt erzeugt wird und mit allen, für den Query relevanten Objekten zu befüllen ist (Tabellen, Spalten, Aggregatfunktionen etc.). Dieser Query soll über das Database-Objekt welches den MySQLDatabaseDriver zur Hilfe nimmt ausgeführt werden. Als Rückgabe gibt es ein Objekt vom Typ DBResult.

Objekte zur Darstellung von Tabellen und Spalten habe ich aus 3 Gründen eingeführt:

- In dem System wo mein OR-Mapper zum Einsatz kommen soll werden Erweiterungen während ihrer Installation in der Lage sein müssen die Datenbank um Tabellen/Spalten zu erweitern. Ich kann somit die Möglichkeit anbieten ohne großartiges Query gekaspert mit Funktionen wie addTable() o.Ä. zu arbeiten welche dann den benötigten Query erzeugt.

- Aus oben genannten Grund kann ich andere Aufgaben wie Zählen von Datensätzen auch einfach über Memberfunktionen des entsprechendem Objektes realisieren. Erspart mir erneut für einige Routineaufgaben das manuelle Erzeugen eines DBQuery Objektes.

- Würde ich Spalten und Tabellen nicht als Objekte abbilden laufe ich meiner Meinung nach in ein anderes Problem betreffend der WHERE Klausel der Queries. Würde ich folgendes amchen:

PHP-Code:

  $where = new DBWhere('username', 'equal', $_POST['username']);

Dann renne ich in das starre Konzept das der erste Parameter eine Tabellenspalte sein muss und der dritte Parameter der Vergleichswert da ich ansonsten nicht identifizieren kann ob es sich nun um einen String oder einen Namen einer Tabellenspalte handelt.

Folgendes wäre nicht möglich:

PHP-Code:

  $columLeft = $userTable->getColumn('id');

$columRight = $groupTable->getColumn('user_id');

 
$onClause = new DBWhere($columnLeft, 'equal', $columnRight);

Wenn man davon ausgeht das getColumn() Objekte vom Typ DBColumn zurückliefert habe ich somit in $onClause ein perfektes Objekt für die ON Klausel eines Join.

Selbiges gilt für die Tabellen und ihre Namen.

Das Driver-Objekt setzt dann ledeglich die Objektstruktur welches das DBQuery Objekt enthält in einen SQL-Befehl um und setzt diesen ab.

Mit Synchronisation war zuerst ein Plan das sich die Objekte permanent den Inhalt der Datenbank wiederspiegeln sollten. Das habe ich aber schon länger verworfen.

Chriz · 30.01.2010, 14:49

Du wirst damit scheitern. Die großen Frameworks haben sich da auch rausgehalten, weil du WHERE-Bedingungen einfach nicht sinnvoll und nicht so effektiv abbilden kannst.

WHERE IN (1, 4, 1215) AND (status = 1 OR activated = 1) AND (SUBSTR(description, 0, 10) LIKE '%schnurz% OR logins > 5).

Wie willst du das kürzer objektorientiert abbilden? Warum verkomplizieren? Nicht überall macht OOP Sinn. Außerdem, wie stellst du Formatierungen dar? Bedingungen in ORDER-Clauses. Such dir erstmal einen richtig komplizierten Query raus und schau, ob du den irgendwie in deine Objektstruktur reinbekommst, ohne dabei Codemonster zu erzeugen.

Zend_Db_Select macht das sehr elegant, in dem das Objekt eine __toString() Methode implementiert, die dir den SELECT-Query eben per String zurückliefert. Die fetch-Methoden erwarten einen String. So kannst du das Objekt benutzen, oder eben deinen eigenen Query zusammenbauen.

Ich wills dir aber nicht verderben oder ausreden, nur ich habe meine Versuche diesbezüglich schon hinter mir und glaube nicht, dass eine wirklich sinnvolle Lösung drinne ist.

Dark Guardian · 30.01.2010, 15:54

Zitat:

Zitat von Chriz

WHERE IN (1, 4, 1215) AND (status = 1 OR activated = 1) AND (SUBSTR(description, 0, 10) LIKE '%schnurz% OR logins > 5).

Pseudocode sähe ganz spontan entschieden warscheinlich so aus:

PHP-Code:

  $query = new DBQuery();

$columns = $table->getColumns('id', 'status', 'activated', 'description', 'logins');

 
$subStrFunc = new DBFunc('substr', array($columns['description'], 0, 10));

 
$whereIn          = new DBWhere($columns['id'],        'in',      array(1, 4, 1215));

$whereStatus      = new DBWhere($columns['status'],    'equal',   1                );

$whereActivated   = new DBWhere($columns['activated'], 'equal',   1                );

$whereDescription = new DBWhere($subStrFunc,           'like',    '%schnurz%'      );

$whereLogins      = new DBWhere($columns['logins'],    'greater', 5                );

 
$whereStatusOrActive      = $query->combinedWhere($whereStatus,      'OR', $whereActivated);

$whereDescriptionOrLogins = $query->combinedWhere($whereDescritpion, 'OR', $whereLogins);

 
$fullWhere = $query->combinedWhere($whereIn, 'and', $whereStatusOrActive, 'and', $whereDescriptionOrLogins);

Das obige ist in der Tat ein Codemonster, aber abbilden ließe es sich.

Von kürzer abbilden ist auch im Prinzip keine Rede gewesen. Ich möchte es nur so abbilden das ich mit einem zugrundeliegenden Driver-Objekt das ganze für verschiedene DBMS "konvertieren" kann.

Sicherlich werde ich auch eine Möglichkeit vorsehen Queries eigenständig einzugeben ohne die Objektstruktur nutzen zu müssen.

Das Problem ist dann aber was passiert wenn es die Substr() Methode im verwendetem DBMS nicht gibt? In meinem Fall hätte das Driver-Objekt, wie auch immer, noch die Möglichkeit darauf zu reagieren und ggf. eine vom DBMS bereitgestellte äquivalente Funktion zu nutzen, die Angabe zu ignorieren oder einen Fehler zu werfen. Letzteres würde die Umsetzung aber in der Tat sinnlos machen da bei einem Handgeschriebenem Query wohl auch ein Fehler zustande käme.

DBWhere sollte auch eher DBCondition heißen. Das trifft den Verwendungszweck erheblich besser und erklärt auch wie Bedingungen in Order By Klauseln zu realisieren wären.

Bei derartigen Monsterqueries wäre es auch kein größeres Problem den "fertigen" Query als prepared Statement für jeden installierten Datenbankteiber zu speichern. Die PDO emuliert diese ja sogar für DBMS welche sie nicht unterstützen. Das gehört aber zu dem umliegendem System und nicht direkt zum OR-Mapper.

Code:

Ich wills dir aber nicht verderben oder ausreden, nur ich habe meine Versuche diesbezüglich schon hinter mir und glaube nicht, dass eine wirklich sinnvolle Lösung drinne ist.

Ich bin mir bewusst das eine 100%ig perfekte Lösung die auf alles passt nicht drin ist. Eine eierlegende Wollmilchsau soll es ja auch gar nicht werden (dann könnte ich gleich Doctrine nutzen). Ich möchte im Prinzip nur herköämmliche Standardqueries DBMS nutzen können ohe mir da großartig Sorgen machen zu müssen und um mir bei Standardaufgaben durch Objekte einfach Arbeit abnehmen zu lassen.

robo47 · 30.01.2010, 16:18

Zitat:

Zitat von Chriz

Zend_Db_Select macht das sehr elegant, in dem das Objekt eine __toString() Methode implementiert, die dir den SELECT-Query eben per String zurückliefert. Die fetch-Methoden erwarten einen String. So kannst du das Objekt benutzen, oder eben deinen eigenen Query zusammenbauen.

Beim ZF hat man ja für all die exotischeren Dinge in Querys die nicht abgedeckt sind, egal was es ist, dann Zend_Db_Expr, da lässt sich alles reinpacken und die DB-Klasse rührt das in keiner Form an sondern wandelt es in einen String um und fertig, also alles was non-standard ist unterzubringen ist damit möglich.

Aber wie ich früher schon gesagt hab, so ein System neu zu erfinden mit all dem was dieses System können soll, soweit ich den Thread mitgelesen hab, geht fast über das hinaus was andere Systeme in dem Bereich wie Doctrine, Propel, Zend_Db und co zusammen können.

Es klingt einfach nach der eierlegenden Wollmilchsau und wenn sieht sich Doctrine, Propel oder ein anderes ORM-System angeschaut hat und sieht was Sie an Features bieten, von der CMD für sämtliche Generierung/Migration/etc über Tabellen-Generierungen, Migrationen, Fixtures und das alles, dann ist das toll.
Aber man muss auf der anderen Seite dann sehen, wie lange wurde an so einem System entwickelt (Propel seit 2003, Doctrine 2006, Zend_Db 2005) ? Wie viele Leute arbeiten daran (und damit), seien es Entwickler, Benutzer die nur ab und zu mal nen Patch/Bugreport machen und wie sieht auf der anderen Seite dann auch die Performance, Speicherverbrauch und soweiter bei so einer eierlegenden Wollmilchsau aus ?

Und kann man als Einzelperson überhaupt sowas vernünftig stemmen ? Und in welchem Zeitrahmen ? Meiner Meinung nach ist das kein 1-Personen System wenn man nicht gerade zu viel Zeit hat und damit leben kann wenn das System erst nach zig Monaten halbwegs die ganzen Anforderungen sauber abdeckt, etwas getestet wurde und vielleicht im ersten Projekt mal etwas evaluiert wurde um festzustellen welche eventuellen Ecken es hat die man noch ausbügeln sollte/müsste.

Auch beim ZF hat man ja nachdem Benjamin Eberlei die Entwicklung von Zend_Entity abgebrochen hat, dann indirekt auf Doctrine gesetzt, weil er einfach festgestellt hat, es ist ein Haufen Arbeit und Doctrine hat das Rad schon recht rund erfunden und will es mit Doctrine 2 noch runder machen). Dafür wird es eine stärkere Integration von Doctrine 1 und 2 im ZF geben und Eberlei ist jetzt Core-Entwickler bei Doctrine und kümmert sich um die ZF-Integration.
Bei Symfony hat man von anfang an gesagt sie wollen das Rad nicht neu erfinden und haben Propel und später noch Doctrine integriert.

Chriz · 30.01.2010, 16:20

Zitat:

Zitat von Dark Guardian

PHP-Code:

  $query = new DBQuery();
$columns = $table->getColumns('id', 'status', 'activated', 'description', 'logins');

$subStrFunc = new DBFunc('substr', array($columns['description'], 0, 10));

$whereIn          = new DBWhere($columns['id'],        'in',      array(1, 4, 1215));
$whereStatus      = new DBWhere($columns['status'],    'equal',   1                );
$whereActivated   = new DBWhere($columns['activated'], 'equal',   1                );
$whereDescription = new DBWhere($subStrFunc,           'like',    '%schnurz%'      );
$whereLogins      = new DBWhere($columns['logins'],    'greater', 5                );

$whereStatusOrActive      = $query->combinedWhere($whereStatus,      'OR', $whereActivated);
$whereDescriptionOrLogins = $query->combinedWhere($whereDescritpion, 'OR', $whereLogins);

$fullWhere = $query->combinedWhere($whereIn, 'and', $whereStatusOrActive, 'and', $whereDescriptionOrLogins);

Das wird kein Mensch so benutzen, nicht einmal du

robo47 · 30.01.2010, 16:27

// hatte Dark Guardians antwort noch nicht gesehen ... tab zu lange offen

daher gleich noch mehr

Zitat:

Zitat von Dark Guardian

Das Problem ist dann aber was passiert wenn es die Substr() Methode im verwendetem DBMS nicht gibt? In meinem Fall hätte das Driver-Objekt, wie auch immer, noch die Möglichkeit darauf zu reagieren und ggf. eine vom DBMS bereitgestellte äquivalente Funktion zu nutzen, die Angabe zu ignorieren oder einen Fehler zu werfen. Letzteres würde die Umsetzung aber in der Tat sinnlos machen da bei einem Handgeschriebenem Query wohl auch ein Fehler zustande käme.

Das bekommst du eigentlich nur unter wenn du einen kompletten sql-parser hast + "übersetzter" in andere dialekte oder eine eigene sql-ähnliche sprache entwickelst, deine querys in der verfasst und dann von deinem system das "passend" umgesetzt wird in sql für mysql/sqlite/oracle und wenn eine übersetzung nicht möglich ist, fliegt eine Exception.
Das ist ja ~ das was Doctrine mit DQL gemacht hat, eine sql-like-sprache die passend in querys umgesetzt wird und wo man natives SQL einbauen kann.

Zitat:

Ich bin mir bewusst das eine 100%ig perfekte Lösung die auf alles passt nicht drin ist. Eine eierlegende Wollmilchsau soll es ja auch gar nicht werden (dann könnte ich gleich Doctrine nutzen). Ich möchte im Prinzip nur herköämmliche Standardqueries DBMS nutzen können ohe mir da großartig Sorgen machen zu müssen und um mir bei Standardaufgaben durch Objekte einfach Arbeit abnehmen zu lassen.

Aber wenn ich mir anschaue was du eigentlich doch alles willst ist es doch eben mehr als Standard-queries, es ist eben nicht nur eine einfache abstraktion für Querys, sondern ORM soll ein bißchen mit rein, Klassen für einzelne Zeilen, Spalten, Resultsets, Querys, Bedingungen, Where, Abstraktion für server-spezifische befehle um die umzusetzen (was ja nur geht wenn du entweder einen kompletten sql-parser für die verschiedenen sql-dialekte schreibst, oder einen sql-ersatz nimmst).

Dark Guardian · 30.01.2010, 18:09

Zitat:

Zitat von Chriz

Das wird kein Mensch so benutzen, nicht einmal du

Sagte ja ist ein Codemonster. An sowas habe ich auch nicht gedacht. Ich wollte nur zeigen das es "auf Krampf" abzubilden wäre.

Zitat:

Zitat von robo47

(was ja nur geht wenn du entweder einen kompletten sql-parser für die verschiedenen sql-dialekte schreibst, oder einen sql-ersatz nimmst).

Das ist der Grund weswegen ich bisher nur auf konzeptioneller Ebene arbeite und noch (außer Pseudocode) absolut null umgesetzt habe.

Eigentlich will ich gar nicht soooooooooo viel, sondern mir nur die Möglichkeit offenhalten es nachträglich implementieren zu können falls doch einmal der Fall eintritt das meine Implementierung nicht mehr ausreicht. Das geht halt leider nur wenn ich so viel in Einzelteile zerlege wie möglich und den einzelnen Teilen die Möglichkeit der Erweiterbarkeit hinzufüge.

Mag sein das es dadurch gerade so rüberkommt als wolle ich Doctrine nachbauen. Ist aber definitiv nicht so.

Dazu muss ich sagen ich bin ein Mensch der gerne an solchen Dingen etwas knabbert.

Ein Rätsel macht auch keinen Spaß wenn die Lösung auf den Kopf gedruckt drunter steht und man sie lesen kann. Genauso macht mir die konzeptuionelle Entwicklung eines Systems keinen Spaß wenn ich für jede Problemstellung eine Lösung aus dem Netz nehmen könnte.

nikosch · 30.01.2010, 18:13

Zitat:

An sowas habe ich auch nicht gedacht. Ich wollte nur zeigen

Leider ist das Beispiel nicht sonderlich abwegig. Auch JOINS mit komplexen ON-Bedingungen wird ähnliche Listings erzeugen. Genau deswegen stellt sich mir immer die Frage nach der Sinnhaftigkeit von ORM-Mappern etc. Wenn man sich nicht gerade auf die 1 Datensatz = 1 Query Regel herablassen will (Performance good bye) wirds oft doch schon recht haarig.

Themen-Optionen
Druckbare Version zeigen Jemanden per E-Mail auf dieses Thema hinweisen
Thema bewerten
Thema bewerten:

Ähnliche Themen
Thema	Autor	Forum	Antworten	Letzter Beitrag
[Erledigt] Konzept für einen PHP Web Crawler	Dark Guardian	Software-Design	10	23.11.2009 16:31
MVC Konzept	Babbsdrebbler	Software-Design	6	30.10.2009 08:13
Konzept für Bowsergame	Wiillli	Beitragsarchiv	1	21.10.2009 15:18
Grafiker gesucht - BG mit fertigem Konzept und Programmierern	thezug	Beitragsarchiv	0	28.08.2009 15:33
[Erledigt] Konzept Newssammler	larsemann	PHP-Fortgeschrittene	8	03.03.2009 17:20
Objekte und Sessions	boehseronkel	PHP Tipps 2008	17	07.10.2008 10:34
kleines DB Konzept	Tomte	Datenbanken	21	23.08.2008 10:22
dynamische Webseiten - Sitemap: Konzept	dh1sbg	PHP-Fortgeschrittene	4	14.08.2007 13:23
Möchtegern Browsergame	Marian	Trash	57	06.08.2006 03:32
Konzept Frage (2), DB Package	greg	PHP-Fortgeschrittene	0	15.07.2006 14:19
Überdenken des Konzept: Eigene Bildergalerien für User	pixelcut	PHP-Fortgeschrittene	3	16.01.2006 18:40
Konzept GFX-Community		PHP Tipps 2005-2	2	22.08.2005 10:22
[Erledigt] Selectanfrage an eine Datenbank,aber aus mehreren Tabellen		Datenbanken	2	26.10.2004 07:23
[Erledigt] Probleme beim Umsetzen von alten Konzept in Smarty		PHP-Fortgeschrittene	4	13.09.2004 01:43
[Erledigt] Multigaming Warscript Konzept		PHP-Fortgeschrittene	6	30.08.2004 20:56


Mister Ad PHP Code Flüsterer Registriert seit: 21.08.2005 Beiträge: 4682 PHP-Kenntnisse: Fortgeschritten

30.01.2010, 00:36
Chriz Moderator Registriert seit: 11.05.2008 Beiträge: 6.069	Darf ich mal was einschieben? Dein Konzept ist, so wie ichs beim Ueberfliegen aufgefasst habe, konzeptlos Was willst du denn eigentlich machen? ORMapping, TableGateway, eine Datenbankabstraktion, eine Datenbankzugriffsabstraktion? Entscheid dich mal! Bei allem was du machst, abstrahier in Stufen. Kein Entwickler mag es, wenn das Absenden eines manuellen Queries zum Hoelleninferno wird, weil 10 Abstraktionsschichten glauben, sie wuessten was du eigentlich willst. Wenn du wirklich mehrere Datenbanken transparent ansprechen moechtest, versuch Queries als Objekte abzulegen. Zend_Db_Select hat sich da als sehr hilfreich erwiesen, wir nutzens fuer MySQL und Oracle (PDO jeweils). Solangs nicht sehr komplex wird, ist damit alles moeglich. Falls doch, hast du Adapter, die du entsprechend anpassen kannst. Also resete nochmal deine ganzen Plaene von DBTable usw. Ich halte das fuer Murgs. Spaetestens bei nem Join flitzt dir da ein unueberlegtes Konzept gegen die Wand. Synchronisieren wuerde ich komplett streichen. Was auch immer du damit bezwecken wolltest.

30.01.2010, 14:49
Chriz Moderator Registriert seit: 11.05.2008 Beiträge: 6.069	Du wirst damit scheitern. Die großen Frameworks haben sich da auch rausgehalten, weil du WHERE-Bedingungen einfach nicht sinnvoll und nicht so effektiv abbilden kannst. WHERE IN (1, 4, 1215) AND (status = 1 OR activated = 1) AND (SUBSTR(description, 0, 10) LIKE '%schnurz% OR logins > 5). Wie willst du das kürzer objektorientiert abbilden? Warum verkomplizieren? Nicht überall macht OOP Sinn. Außerdem, wie stellst du Formatierungen dar? Bedingungen in ORDER-Clauses. Such dir erstmal einen richtig komplizierten Query raus und schau, ob du den irgendwie in deine Objektstruktur reinbekommst, ohne dabei Codemonster zu erzeugen. Zend_Db_Select macht das sehr elegant, in dem das Objekt eine __toString() Methode implementiert, die dir den SELECT-Query eben per String zurückliefert. Die fetch-Methoden erwarten einen String. So kannst du das Objekt benutzen, oder eben deinen eigenen Query zusammenbauen. Ich wills dir aber nicht verderben oder ausreden, nur ich habe meine Versuche diesbezüglich schon hinter mir und glaube nicht, dass eine wirklich sinnvolle Lösung drinne ist.