PHP-Scripte PHP-Tutorials PHP-Jobs und vieles mehr

PHP-Scripte PHP-Tutorials PHP-Jobs und vieles mehr (https://www.php-resource.de/forum/)
-   PHP Developer Forum (https://www.php-resource.de/forum/php-developer-forum/)
-   -   [OOP] Datenbankeinträge in Objekte speichern? (https://www.php-resource.de/forum/php-developer-forum/90696-oop-datenbankeintraege-in-objekte-speichern.html)

Schnitzel 10-03-2008 16:54

[OOP] Datenbankeinträge in Objekte speichern?
 
Hallo Zusammen

Ich bin am entwickeln eines Syslog-Meldung-Anzeigesystems. Dabei gehts hauptsächlich darum: Ich habe eine MySQL Datenbank welche Syslogmeldungen (mehrere Tausend) enthält. Diese Syslogmeldungen können per IP Adresse an Netzwerkgeräten zugeordnet werden.

Diese Syslogmeldungen will ich nun auf einer Webseite ausgeben das ganze mit JQuery als Javascript Framework und PHP5 OOP. Die OOP Objekte werden in der Session Variable gesichert. So kann ich per AJAX auf die Daten zugreiffen.

Nun frage ich mich wie ihr das lösen würdet: Würdet ihr für jedes Netzwerkgerät im PHP ein Objekt erstellen, welches Informationen, die ich auf der Webseite ausgebe, enthält? Also z.B. die AnzahlMeldungen pro Gerät? Oder würdet ihr diese Informationen jeweils per SQL aus der Datenbank holen und dann weitergeben?

Mein Problem ist halt, dass wenn ich die Daten einmal in Objekten speichere, ich nie herausfinde ob sich die Daten in der SQL geändert habe, denn eigentlich bilde ich ja nur die Datenbank in Objekten ab, welche ich dann aber einfacher ausführen und bearbeiten kann. Will ich trotzdem wissen ob sich die Daten in der Datenbank geändert haben, muss ich eine SQL Query ausführen, die dann aber zwar einfacher zum ausführen und viel weniger Rückgabewerte besitzt. Aber ausgeführt werden muss ich sie ja trotzdem.

Wenn ich die Daten nicht in Objekte speichere sondern direkt dem AJAX von der SQL Datenbank weiterleite, bin ich zwarschneller. Aber ich finde, dann beachte ich die Objektorientierte Programmierung nicht mehr so wirklich.

Gruss

ModestLife 10-03-2008 17: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 17:39

Zitat:

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 17: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 17:59

Zitat:

Original geschrieben von ModestLife
Also so langsam ist PHP dann auch wieder nicht. ;-)
;-) man probiert halt so performant wie möglich zu programmieren :)

Zitat:

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.

Zitat:

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 23: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:
Zitat:

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 09:38

Zitat:

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 21: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 21: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 21: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 22: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 22: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 :D

Slava 11-03-2008 22:41

Zitat:

Original geschrieben von BugBite

und mysql_fetch_object ist die nutzloseste funktion ever :D

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 22:52

Zitat:

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 :p ... 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 :D

Slava 12-03-2008 19:39

Zitat:

Original geschrieben von asp2php
Ähm ... welche Schriftgröße habt ihr denn gewählt :p ... 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 :D
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.
:{


Alle Zeitangaben in WEZ +2. Es ist jetzt 20:59 Uhr.

Powered by vBulletin® Version 3.8.2 (Deutsch)
Copyright ©2000 - 2018, Jelsoft Enterprises Ltd.
Search Engine Friendly URLs by vBSEO 3.3.0
[c] ebiz-consult GmbH & Co. KG