Persistence Framework - Seite 4

dr.e. · 27.03.2009, 22:29

Doch, ich höre dir schon zu...

agrajag · 28.03.2009, 00:43

Schön ist es natürlich, wenn man von lazy loading ohne Probleme auf eager loading umstellen kann. Also ohne dafür dann selbst das Query schreiben zu müssen oder andere Kopfstände zu machen.

Sprich sowas wie:

PHP-Code:

  // ein Post gehört zu einem User, ein User hat beliebig viele Posts
// lädt alls Posts aus der Datenbank, lazy loading
$posts = Post::find('all');
echo $posts[0]->user->name; // lädt für den ersten Post den zugehörigen User aus der Datenbank

//lädt alle Posts und ihre jeweiligen Benutzer aus der Datenbank (1 Query mit JOIN), eager loading
$posts = Post:find('all', array('include' => 'user'));

Wenn es Rails' ActiveRecord auch für PHP geben würde, das wär' toll.

Phoscur · 28.03.2009, 01:59

naja, ich würde einfach eine Einstellungsmöglichkeit geben, bei der bei Lazy Loading (dein erstes Beispiel) trotzdem nur eine zweite (ohne Join sind es ja zwei Queries, eine pro Tabelle) Query verwendet wird, welche dann aber in allen Posts den User bereitstellt. Oder man läd vorher die User der Posts in den Cache.

PHP-Code:

  // ein Post gehört zu einem User, ein User hat beliebig viele Posts
$posts = Post::find('all');
User::findbyIDs(Post::queriedIDs); # lade Userdaten vorraus (erstelle nicht zwingend schon die Objekte, minimal Overhead)
echo $posts[0]->user->name; # erstellt für den ersten Post den zugehörigen User aus dem Cache

So sollten sich sich die Queries auf eine pro Tabelle beschränken.

Wie selektierst du eigentlich User und Posts in einer Query? Mit JOIN ist klar, aber wie bekommst du die Daten der beiden? Brauchst du da nicht zwei Queries?

#Avedo · 28.03.2009, 02:16

Ich muss persönlich sagen, dass ich von Lazy Loading nur sehr wenig halte. Ich denke die Domain Objekte sollten soweit wie möglich von der Datenbank getrennt werden. In meiner Implementierung wissen die Objekte nichts außer dem Namen ihrer Domäne. Sowohl die Datenbank-Struktur, als auch alle Methoden zum ansprechen der Datenbank sind vollkommen von den Domain Objekten getrennt.

Leider muss ich gestehen, dass ich nicht die Zeit und die Lust hatte Eager Loading in die Mapper Klasse zu implementieren. Das sorgt dafür, dass sich das Laden von in Relation stehenden Objekten etwas unschön gestaltet, jedoch finde ich das nun auch nicht so schlimm.

MfG, Andy

@Phlegma
Ja ich brauche zwei Queries, aber du hast ja auch ein sehr günstiges Beispiel genommen. Dort ist das nicht wirklich schlimm. Und wenn du nun alle Posts eines Nutzers benötigst, dann brauch man auch bei eurer Methode ohne ein geeignetes QueryObject sehr sehr viele Queries. Deshalb kommt man wohl um eine solche Implementierung nicht herum, ich denke dass sollte aber auch vollkommen reichen.

agrajag · 28.03.2009, 11:09

Zitat:

Zitat von Phlegma

PHP-Code:

  // ein Post gehört zu einem User, ein User hat beliebig viele Posts
$posts = Post::find('all');
User::findbyIDs(Post::queriedIDs); # lade Userdaten vorraus (erstelle nicht zwingend schon die Objekte, minimal Overhead)
echo $posts[0]->user->name; # erstellt für den ersten Post den zugehörigen User aus dem Cache

So sollten sich sich die Queries auf eine pro Tabelle beschränken.

Wie selektierst du eigentlich User und Posts in einer Query? Mit JOIN ist klar, aber wie bekommst du die Daten der beiden? Brauchst du da nicht zwei Queries?

Ähm, das oben war nur Code wie ich ihn mir wünschen würde. Mir das so umfangreich selbst zu basteln wie ich es mir wünscche traue ich mir leider nicht zu

Gehen tut es aber in einem Query. CakePHP kann das zum Beispiel. Wie genau weiß ich jetzt aus dem Stehgreif auch nicht mehr. Im Extremfall müsstse man jedem Feld einen Alias mit dem Model-Namen geben:

Zitat:

SELECT posts.body AS PostBody, posts.xyz AS PostXYZ, users.name AS UserName, ... FROM posts JOIN users ON ...

und dann das Ergebnis entsprechend parsen.

Zitat:

Zitat von #Avedo

Ja ich brauche zwei Queries, aber du hast ja auch ein sehr günstiges Beispiel genommen. Dort ist das nicht wirklich schlimm. Und wenn du nun alle Posts eines Nutzers benötigst, dann brauch man auch bei eurer Methode ohne ein geeignetes QueryObject sehr sehr viele Queries.

Naja nicht unbedingt. In dem einfachen Fall:

PHP-Code:

  $user = User::find($user_id, array('include' => 'posts'));

wäre das wieder nur ein Query mit JOIN.
Und wenn du hier:

PHP-Code:

  $posts = Post::find('all');

Nicht nur die User "eager" haben willst sondern auch für jeden User alle seine Posts dann sollte das so gehen:

PHP-Code:

  $posts = Post::find('all', array('include' => array('user' => 'posts')));

Dann wäre es immernoch ein Query (SELECT .. FROM posts post JOIN users user ON post.user_id = user.id JOIN posts all_posts ON user.id = all_posts.user_id).
(Schnell oder performant ist das dann natürlich dann auch nicht immer weil die Datenmengen natürlich unter Umständen riesig werden....)

[alles nur Phantasiecode, wobei es in CakePHP tatsächlich ähnlich geht, nur gibt's dort garkein lazy loading und es werden auch keine Objekte sondern nur Arrays zurückgegeben]

#Avedo · 28.03.2009, 11:32

Wie gesagt halte ich Lazy Loading auch für so eine Sache. Zudem muss ich sagen, dass ich ein kleines Problem mit Joins etc. habe. Natürlich ist es nett alles über Joins laden zu können, aber die so geladenen Objekte sind nur sehr schwer zu verwalten. Es ist meines erachtens kaum möglich mit einem Vernünftigen Aufwand-Nutzen Verhältnis ein System zu schaffen, dass das Laden von Objekten oder Arrays mit Hilfe von Joins ermöglicht, es dann aber auch ermöglicht Änderungen an den Objekten oder gar an den Objektbäumen zu speichern. Daher bin ich auch der Meinung, dass eine Implementierung eines DataMappers so schlank und "rein" wie möglich gehalten werden sollte. Zum fortgeschritteneren Laden von Objekten kann man ein einfaches QueryObject implementieren, dass vorallem Bedingungen etc unterstützt.
MfG, Andy

Phoscur · 28.03.2009, 13:37

Zitat:

Code:

SELECT posts.body AS PostBody, posts.xyz AS PostXYZ, users.name AS UserName, ... FROM posts JOIN users ON ...

und dann das Ergebnis entsprechend parsen.

Naja "parsen".. beschneiden würde ich das eher nennen... Irgendwie kommt mir das Query unperformant vor, auch wenn es das vielleicht nicht ist. Auf jeden Fall musst du danach einen Haufen doppelte Informationen wieder rausschmeißen..
Wie Avedo auch schon richtig meinte, ist das Update dann noch schwieriger. Ich würde bei zwei Queries bleiben, wenn du mir nicht beweisen kannst, dass das eine wirklich doppelt so schnell ist (nicht dass du das gesagt hättest, aber erst dann lohnt sich für mich der extra Aufwand).

Bisher habe ich einen Mapper pro Tabelle und rechne pro Skriptaufruf optimiert mit einer Query pro Mapper/Tabelle. Die Interaktion zwischen den Mappern ist der größte Spaß, da beginnen nämlich die Probleme, erst recht wenn man zu Kapselung und loser Kopplung geneigt ist.

dr.e. · 28.03.2009, 17:32

Zitat:

Die Interaktion zwischen den Mappern ist der größte Spaß, da beginnen nämlich die Probleme, erst recht wenn man zu Kapselung und loser Kopplung geneigt ist.

Das geht auch nicht. Wenn man das domain object pattern in Verbindung mit dem DataMapper nutzen möchte, muss man sich von loser Kopplung verabschieden. Denn: man geht dort immer von einem größeren Datenmodell aus, als es in der Domäne benötigt wird. IMHO ist alles lose koppeln zu wollen ein ziemlicher Unfug!

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
PHP Application Framework	root66	PHP-Fortgeschrittene	6	13.02.2009 22:45
Suche Schüler o.ä. mit Zend Framework Erfahrung -> 200 Euro	mrmojo	Beitragsarchiv	3	10.01.2009 15:38
CMS mit Framework	KeKs0r	PHP-Fortgeschrittene	11	27.12.2008 23:03
Zend Studio for Eclipse und Zend Framework	KeKs0r	PHP-Fortgeschrittene	5	15.12.2008 15:10
Release 1.8 (RC1) des Adventure PHP Framework verfügbar!	dr.e.	Beitragsarchiv	4	11.12.2008 09:44
Bestehende Seite in Framework einbinden	MaWe4585	PHP-Fortgeschrittene	1	16.10.2008 08:20
Suche nach Framework für schnelles programmieren	BLACK	PHP Tipps 2008	4	13.08.2008 04:54
Release 1.7 beta des Adventure PHP Framework verfügbar!	dr.e.	Beitragsarchiv	2	30.07.2008 17:50
BrickOO :: PHP Framework	Hroudtwolf	Scriptbörse	14	06.05.2008 12:04
Zend Framework	Melchior	PHP-Fortgeschrittene	29	13.03.2008 21:12
framework struktur	notyyy	PHP Tipps 2008	3	06.11.2007 18:19
Framework aus Haupt und Unterverzeichnis nutzen?	Anotherone	PHP-Fortgeschrittene	8	24.07.2007 15:05
[Erledigt] Framework empfehlen?		PHP-Fortgeschrittene	1	01.06.2004 07:56

27.03.2009, 22:29
dr.e. Moderator und Wett-König Registriert seit: 21.05.2008 Beiträge: 3.657 PHP-Kenntnisse: Fortgeschritten	Doch, ich höre dir schon zu... __________________ Viele Grüße, Dr.E. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 1. Think about software design before you start to write code! 2. Discuss and review it together with experts! 3. Choose good tools (-> Adventure PHP Framework (APF))! 4. Write clean and reusable software only! ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~


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

28.03.2009, 00:43
agrajag Moderator Registriert seit: 02.10.2006 Beiträge: 3.820 PHP-Kenntnisse: Fortgeschritten	Schön ist es natürlich, wenn man von lazy loading ohne Probleme auf eager loading umstellen kann. Also ohne dafür dann selbst das Query schreiben zu müssen oder andere Kopfstände zu machen. Sprich sowas wie: PHP-Code: `// ein Post gehört zu einem User, ein User hat beliebig viele Posts // lädt alls Posts aus der Datenbank, lazy loading $posts = Post::find('all'); echo $posts[0]->user->name; // lädt für den ersten Post den zugehörigen User aus der Datenbank //lädt alle Posts und ihre jeweiligen Benutzer aus der Datenbank (1 Query mit JOIN), eager loading $posts = Post:find('all', array('include' => 'user'));` Wenn es Rails' ActiveRecord auch für PHP geben würde, das wär' toll. __________________ Today you...Tomorrow me.

28.03.2009, 01:59
Phoscur Erfahrener Benutzer Registriert seit: 01.12.2008 Beiträge: 450 PHP-Kenntnisse: Fortgeschritten	naja, ich würde einfach eine Einstellungsmöglichkeit geben, bei der bei Lazy Loading (dein erstes Beispiel) trotzdem nur eine zweite (ohne Join sind es ja zwei Queries, eine pro Tabelle) Query verwendet wird, welche dann aber in allen Posts den User bereitstellt. Oder man läd vorher die User der Posts in den Cache. PHP-Code: `// ein Post gehört zu einem User, ein User hat beliebig viele Posts $posts = Post::find('all'); User::findbyIDs(Post::queriedIDs); # lade Userdaten vorraus (erstelle nicht zwingend schon die Objekte, minimal Overhead) echo $posts[0]->user->name; # erstellt für den ersten Post den zugehörigen User aus dem Cache` So sollten sich sich die Queries auf eine pro Tabelle beschränken. Wie selektierst du eigentlich User und Posts in einer Query? Mit JOIN ist klar, aber wie bekommst du die Daten der beiden? Brauchst du da nicht zwei Queries? __________________

28.03.2009, 02:16
#Avedo Erfahrener Benutzer Registriert seit: 06.09.2008 Beiträge: 189	Ich muss persönlich sagen, dass ich von Lazy Loading nur sehr wenig halte. Ich denke die Domain Objekte sollten soweit wie möglich von der Datenbank getrennt werden. In meiner Implementierung wissen die Objekte nichts außer dem Namen ihrer Domäne. Sowohl die Datenbank-Struktur, als auch alle Methoden zum ansprechen der Datenbank sind vollkommen von den Domain Objekten getrennt. Leider muss ich gestehen, dass ich nicht die Zeit und die Lust hatte Eager Loading in die Mapper Klasse zu implementieren. Das sorgt dafür, dass sich das Laden von in Relation stehenden Objekten etwas unschön gestaltet, jedoch finde ich das nun auch nicht so schlimm. MfG, Andy @Phlegma Ja ich brauche zwei Queries, aber du hast ja auch ein sehr günstiges Beispiel genommen. Dort ist das nicht wirklich schlimm. Und wenn du nun alle Posts eines Nutzers benötigst, dann brauch man auch bei eurer Methode ohne ein geeignetes QueryObject sehr sehr viele Queries. Deshalb kommt man wohl um eine solche Implementierung nicht herum, ich denke dass sollte aber auch vollkommen reichen. __________________ I'm so tired of slitting the throats of people calling me a violent psychopath. Geändert von #Avedo (28.03.2009 um 02:21 Uhr).

28.03.2009, 11:32
#Avedo Erfahrener Benutzer Registriert seit: 06.09.2008 Beiträge: 189	Wie gesagt halte ich Lazy Loading auch für so eine Sache. Zudem muss ich sagen, dass ich ein kleines Problem mit Joins etc. habe. Natürlich ist es nett alles über Joins laden zu können, aber die so geladenen Objekte sind nur sehr schwer zu verwalten. Es ist meines erachtens kaum möglich mit einem Vernünftigen Aufwand-Nutzen Verhältnis ein System zu schaffen, dass das Laden von Objekten oder Arrays mit Hilfe von Joins ermöglicht, es dann aber auch ermöglicht Änderungen an den Objekten oder gar an den Objektbäumen zu speichern. Daher bin ich auch der Meinung, dass eine Implementierung eines DataMappers so schlank und "rein" wie möglich gehalten werden sollte. Zum fortgeschritteneren Laden von Objekten kann man ein einfaches QueryObject implementieren, dass vorallem Bedingungen etc unterstützt. MfG, Andy __________________ I'm so tired of slitting the throats of people calling me a violent psychopath.