[OOP] Datenbankeinträge in Objekte speichern?

**ModestLife** · 10.03.2008, 16:20

Hä?

Du kannst doch die Daten bei jedem Request aus der Datenbank holen und in Objekten abbilden? Die musst du doch nicht in der Session speichern? Guck dir mal Doctrine oder Propel an, die schreiben dir sogar die Klassen für's OR-Mapping ... :-)

**Schnitzel** · 10.03.2008, 16:39

Original geschrieben von ModestLife
Hä?

Du kannst doch die Daten bei jedem Request aus der Datenbank holen und in Objekten abbilden? Die musst du doch nicht in der Session speichern?

Ja aber das braucht ja ultra viel Zeit, klar wenn ich mit den Objekten noch sehr viel sonstiges anfangen will. Aber bei meinem Projekt brauche ich hauptsächlich die Daten aus der Datenbank. So würde ich zuerst aus den Datenbanksätzen Objekte erstellen und dann aus diesen Objekten die Daten wieder auslesen. So kann ich mir den Weg über die Objekte sparen.

Und warum soll ich keine Objekte in den Session Variablen speichern? Klar bei Objekten die aus Informationen aus der Datenbank bestehen macht das Sinn. Aber sonstige Objekte die für die verarbeitung zuständig sind (Controller, z.b.) muss ich ja nicht bei jedem AJAX Request wieder neu erstellen.

**ModestLife** · 10.03.2008, 16:44

Also so langsam ist PHP dann auch wieder nicht. ;-)

Du musst dir ja immer nur die Daten aus der DB holen, die du auch brauchst. Du wirst ja wohl nicht 100'000 Datensätze auf einer Seite darstellen. Ausserdem könntest du z.B. direkt die erzeugten PHP Objekte cachen und diese aktualisieren, wenn sich was in der DB ändert.

Ich würde da an deiner Stelle erst mal einen Performancetest machen, bevor du den "falschen" Weg beschreitest.

**Schnitzel** · 10.03.2008, 16:59

Original geschrieben von ModestLife
Also so langsam ist PHP dann auch wieder nicht. ;-)

;-) man probiert halt so performant wie möglich zu programmieren

Original geschrieben von ModestLife
Ausserdem könntest du z.B. direkt die erzeugten PHP Objekte cachen und diese aktualisieren, wenn sich was in der DB ändert.

Und wie cache ich die? In der Session Variable? Die frage ist halt wie ich das genau programmiere. Denn ich frage mich was schneller ist:

A: Zuerst nachschauen welche Datensätze sich verändert haben und erst dann alle Datensätze die sich geändert haben zu speichern.

B: Ohne nachzuschauen welche sich geändert haben alle benötigten Objekte zu erstellen.

Original geschrieben von ModestLife
Ich würde da an deiner Stelle erst mal einen Performancetest machen, bevor du den "falschen" Weg beschreitest.

Das wird wohl nötig sein.

**PHP-Desaster** · 10.03.2008, 22:44

Du kannst an dieser Stelle natürlich zwei Wege gehen:
Einen wahrscheinlich recht fixen Weg, in dem du die Datenbankwerte einfach an dein JS weiterreichst aber super eklig zu pflegen ist.
Oder einen objektorientierten, durch Caching ähnlich fixen Weg, den du auch später gut erweitern/ändern kannst.
Für mich wäre die Entscheidung klar

Btw:

man probiert halt so performant wie möglich zu programmieren

Der heutige Ansatz der Softwareentwicklung setzt eher auf Wiederverwendbarkeit und Übersicht -> OOP.

**Schnitzel** · 11.03.2008, 08:38

Original geschrieben von PHP-Desaster
Oder einen objektorientierten, durch Caching ähnlich fixen Weg,

Und diese Aufgabe würdet ihr einem ORM übergeben?

**Slava** · 11.03.2008, 20:29

<<
dann beachte ich die Objektorientierte Programmierung nicht mehr so wirklich
>>
OOP ist kein Ziehl, sondern ein Weg. Es ist unnötig auf eine ohnehin objektorientierte Datenbankmodel eine zusätzliche Schicht legen, um ein gutes Gefühl zu bekommen, dass du für OOP alles gegeben hast

.
betrachte das mal anderes, OOP ist für dich ausgedacht um deine Arbeit einfacher zu gestalten. Also packe deine SQL-abfragen in die Methoden von einem Objekt und lass diese Methoden zum Laufzeit aufrufen.
Dann hast du dein Objekt, der ein Sicht auf die Daten bietet,
die gute Performance und übersichtliche Quellcode, wo man an Hand von Methodennamen schon der Sinn und Zweck von Anwendung versteht.

'Propel' würde ich nur denjenigen empfehlen, der von SQL keine Ahnung hat. Es ist gut, wenn man die einfache dinge rausfinden möchte, aber für die komplexe Abfragen ist es gar nicht geeignet.
Das behaupte ich, da ich in moment mit 311 Tabellen arbeite und unsere Abfragen sehr komplex sind (die grösste etwa 17 A4 Seiten lang ist) und durchschnittlich 7 Joins haben. Propel würde an dieser stelle (vermutlich) abschmieren.

**BugBite** · 11.03.2008, 20:39

ja das ist ein leidiges thema mit datenbanken und oop, denn es passt hald nicht zusammen:
oop - relationales design

ich hab mir auch schon sehr oft den kopf darüber zerbrochen...
ich für meinen habe jetzt meistens eine save und eine statische load methode in meinen objekten dabei,
welche wiederum alle von einem SqlLinkedObject erben, das ein id attribut mit dazugeörigem getter vererbt.

wenn du die kommunikation zwischen db und server bündeln willst,
kannst du ja erstmal querys in einem objekteigenen cache sammeln und
dann im save committen oder so

ansonsten verweise is auf slavas post

**PHP-Desaster** · 11.03.2008, 20:55

Soweit ich mich in Propel auskenne kannst du auch direkt SQL ausführen. Dann verwendest du die Objekte lediglich als Datenträger. Da kannst du dann aber auch direkt eine der *sql_fetch_object Funktionen verwenden.

**Slava** · 11.03.2008, 21:06

sql_fetch_object kann ich auch mit PDO aufrufen

also warum dan Propel? nur weil er mir bei einer Abfrage über 2 Tabellen helfen kann?
mein sql befehl sieht ein paar CM länger aus, und deckt alle Fragen auf.

**BugBite** · 11.03.2008, 21:30

aaallerdings und das muss man mal pro ORM gesagt haben:
--> objektassoziationen kann man damit fein umsetzen
bis du das händisch machst, biste n gutes weilchen beschäftigt,
speziell bei komplizierteren objektstrukturen mit rekursiven assoziationen etc

und mysql_fetch_object ist die nutzloseste funktion ever

**Slava** · 11.03.2008, 21:41

Original geschrieben von BugBite

und mysql_fetch_object ist die nutzloseste funktion ever

ja! mit fetch_array kann man genau so gut arbeiten.
Wie stellst du dir eigentlich deine Objecte vor?
Wie würdest du es in deiner Anwendug gerne behandeln und welche Methoden hast du dir vorgestellt?
villeicht kann ich an hand von diesen Beschreibungen eine passende implementierung vorschlagen.

**asp2php** · 11.03.2008, 21:52

Original geschrieben von Slava
...Das behaupte ich, da ich in moment mit 311 Tabellen arbeite und unsere Abfragen sehr komplex sind (die grösste etwa 17 A4 Seiten lang ist) und durchschnittlich 7 Joins haben.

Ähm ... welche Schriftgröße habt ihr denn gewählt

... 17 Seiten A4 ... da macht ihr was falsch ... behaupte ich einfach mal

... für eine Stored Procedure ist es auch schon zu viel, aber für eine Abfrage ist es entschieden zu lang ... überprüfe mal die Möglichkeiten

**Slava** · 12.03.2008, 18:39

Original geschrieben von asp2php
Ähm ... welche Schriftgröße habt ihr denn gewählt ... 17 Seiten A4 ... da macht ihr was falsch ... behaupte ich einfach mal ... für eine Stored Procedure ist es auch schon zu viel, aber für eine Abfrage ist es entschieden zu lang ... überprüfe mal die Möglichkeiten

es gibt tatsächlich die queris, die beim ausdrucken in schrift grösse 10 echte 17 Seiten bringen. Wenn mann formatierung weg niemt, dann wird es vielleicht 7 Seiten gross sein, aber dann versteht wirklich kein Mensch mehr (ich verstehe das auch formatiert nicht wirklich

).
manche Tabellen haben mehr als 100 Felder( die man wirklich braucht und nicht in andere Tabellen gehören) und es dauert evigkeit in einer dropdownliste nach passende felder zu suchen.
die software wurde einfach in diesem Zustand übernommen.
Die Moglichkeit neu zu programmieren gibt es nicht und bei Optimisation weist du nicht wo es bei der änderung knallen wird, da es sich um 2135 .php, .inc und .js dateien handelt.

[OOP] Datenbankeinträge in Objekte speichern?