php-resource



Zurück   PHP-Scripte PHP-Tutorials PHP-Jobs und vieles mehr > Entwicklung > PHP Developer Forum
 

Login

 
eingeloggt bleiben
star Jetzt registrieren   star Passwort vergessen
 

 

 


PHP Developer Forum Hier habt ihr die Möglichkeit, eure Skriptprobleme mit anderen Anwendern zu diskutieren. Seid so fair und beantwortet auch Fragen von anderen Anwendern. Dieses Forum ist sowohl für ANFÄNGER als auch für PHP-Profis! Fragen zu Laravel, YII oder anderen PHP-Frameworks.

Antwort
 
LinkBack Themen-Optionen Thema bewerten
  #1 (permalink)  
Alt 10-03-2008, 15:54
Schnitzel
 Newbie
Links : Onlinestatus : Schnitzel ist offline
Registriert seit: Feb 2005
Beiträge: 11
Schnitzel ist zur Zeit noch ein unbeschriebenes Blatt
Standard [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
Mit Zitat antworten
  #2 (permalink)  
Alt 10-03-2008, 16:20
ModestLife
 Registrierter Benutzer
Links : Onlinestatus : ModestLife ist offline
Registriert seit: Sep 2007
Beiträge: 105
ModestLife ist zur Zeit noch ein unbeschriebenes Blatt
Standard

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 ... :-)
Mit Zitat antworten
  #3 (permalink)  
Alt 10-03-2008, 16:39
Schnitzel
 Newbie
Links : Onlinestatus : Schnitzel ist offline
Registriert seit: Feb 2005
Beiträge: 11
Schnitzel ist zur Zeit noch ein unbeschriebenes Blatt
Standard

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.
Mit Zitat antworten
  #4 (permalink)  
Alt 10-03-2008, 16:44
ModestLife
 Registrierter Benutzer
Links : Onlinestatus : ModestLife ist offline
Registriert seit: Sep 2007
Beiträge: 105
ModestLife ist zur Zeit noch ein unbeschriebenes Blatt
Standard

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.
Mit Zitat antworten
  #5 (permalink)  
Alt 10-03-2008, 16:59
Schnitzel
 Newbie
Links : Onlinestatus : Schnitzel ist offline
Registriert seit: Feb 2005
Beiträge: 11
Schnitzel ist zur Zeit noch ein unbeschriebenes Blatt
Standard

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.
Mit Zitat antworten
  #6 (permalink)  
Alt 10-03-2008, 22:44
PHP-Desaster
 PHP Expert
Links : Onlinestatus : PHP-Desaster ist offline
Registriert seit: Mar 2006
Beiträge: 3.105
PHP-Desaster befindet sich auf einem aufstrebenden Ast
Standard

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.
Mit Zitat antworten
  #7 (permalink)  
Alt 11-03-2008, 08:38
Schnitzel
 Newbie
Links : Onlinestatus : Schnitzel ist offline
Registriert seit: Feb 2005
Beiträge: 11
Schnitzel ist zur Zeit noch ein unbeschriebenes Blatt
Standard

Zitat:
Original geschrieben von PHP-Desaster
Oder einen objektorientierten, durch Caching ähnlich fixen Weg,
Und diese Aufgabe würdet ihr einem ORM übergeben?
Mit Zitat antworten
  #8 (permalink)  
Alt 11-03-2008, 20:29
Slava
 PHP Senior
Links : Onlinestatus : Slava ist offline
Registriert seit: Nov 2002
Ort: Köln->Karlsruhe
Beiträge: 1.589
Slava befindet sich auf einem aufstrebenden Ast
Standard

<<
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.
__________________
Slava
bituniverse.com
Mit Zitat antworten
  #9 (permalink)  
Alt 11-03-2008, 20:39
BugBite
 Member
Links : Onlinestatus : BugBite ist offline
Registriert seit: May 2006
Beiträge: 299
BugBite ist zur Zeit noch ein unbeschriebenes Blatt
Standard

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
Mit Zitat antworten
  #10 (permalink)  
Alt 11-03-2008, 20:55
PHP-Desaster
 PHP Expert
Links : Onlinestatus : PHP-Desaster ist offline
Registriert seit: Mar 2006
Beiträge: 3.105
PHP-Desaster befindet sich auf einem aufstrebenden Ast
Standard

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.
Mit Zitat antworten
  #11 (permalink)  
Alt 11-03-2008, 21:06
Slava
 PHP Senior
Links : Onlinestatus : Slava ist offline
Registriert seit: Nov 2002
Ort: Köln->Karlsruhe
Beiträge: 1.589
Slava befindet sich auf einem aufstrebenden Ast
Standard

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.
__________________
Slava
bituniverse.com
Mit Zitat antworten
  #12 (permalink)  
Alt 11-03-2008, 21:30
BugBite
 Member
Links : Onlinestatus : BugBite ist offline
Registriert seit: May 2006
Beiträge: 299
BugBite ist zur Zeit noch ein unbeschriebenes Blatt
Standard

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
Mit Zitat antworten
  #13 (permalink)  
Alt 11-03-2008, 21:41
Slava
 PHP Senior
Links : Onlinestatus : Slava ist offline
Registriert seit: Nov 2002
Ort: Köln->Karlsruhe
Beiträge: 1.589
Slava befindet sich auf einem aufstrebenden Ast
Standard

Zitat:
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.
__________________
Slava
bituniverse.com
Mit Zitat antworten
  #14 (permalink)  
Alt 11-03-2008, 21:52
asp2php
 Banned
Links : Onlinestatus : asp2php ist offline
Registriert seit: Feb 2004
Beiträge: 11.745
asp2php ist zur Zeit noch ein unbeschriebenes Blatt
Standard

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 ... 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
Mit Zitat antworten
  #15 (permalink)  
Alt 12-03-2008, 18:39
Slava
 PHP Senior
Links : Onlinestatus : Slava ist offline
Registriert seit: Nov 2002
Ort: Köln->Karlsruhe
Beiträge: 1.589
Slava befindet sich auf einem aufstrebenden Ast
Standard

Zitat:
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.
__________________
Slava
bituniverse.com
Mit Zitat antworten
Antwort

Lesezeichen


Aktive Benutzer in diesem Thema: 1 (Registrierte Benutzer: 0, Gäste: 1)
 

Themen-Optionen
Thema bewerten
Thema bewerten:

Forumregeln
Es ist Ihnen nicht erlaubt, neue Themen zu verfassen.
Es ist Ihnen nicht erlaubt, auf Beiträge zu antworten.
Es ist Ihnen nicht erlaubt, Anhänge hochzuladen.
Es ist Ihnen nicht erlaubt, Ihre Beiträge zu bearbeiten.

BB-Code ist an.
Smileys sind an.
[IMG] Code ist an.
HTML-Code ist aus.
Trackbacks are an
Pingbacks are an
Refbacks are an


PHP News

ebiz-trader 7.5.0 mit PHP7 Unterstützung veröffentlicht
ebiz-trader 7.5.0 mit PHP7 Unterstützung veröffentlichtDie bekannte Marktplatzsoftware ebiz-trader ist in der Version 7.5.0 veröffentlicht worden.

28.05.2018 | Berni

Wissensbestand in Unternehmen
Wissensbestand in UnternehmenLebenslanges Lernen und Weiterbilden sichert Wissensbestand in Unternehmen

25.05.2018 | Berni


 

Aktuelle PHP Scripte

PHP Server Monitor

PHP Server Monitor ist ein Skript, das prüft, ob Ihre Websites und Server betriebsbereit sind.

11.09.2018 Berni | Kategorie: PHP/ Security
PHP WEB STATISTIK ansehen PHP WEB STATISTIK

Die PHP Web Statistik bietet Ihnen ein einfach zu konfigurierendes Script zur Aufzeichnung und grafischen und textuellen Auswertung der Besuchern Ihrer Webseite. Folgende zeitlichen Module sind verfügbar: Jahr, Monat, Tag, Wochentag, Stunde Folgende son

28.08.2018 phpwebstat | Kategorie: PHP/ Counter
Affilinator - Affilinet XML Produktlisten Skript

Die Affilinator Affilinet XML Edition ist ein vollautomatisches Skript zum einlesen und darstellen der Affili.net (Partnerprogramm Netzwerk) Produktlisten und Produktdaten. Im Grunde gibt der Webmaster seine Affilinet PartnerID ein und hat dann unmittelb

27.08.2018 freefrank@ | Kategorie: PHP/ Partnerprogramme
 Alle PHP Scripte anzeigen

Alle Zeitangaben in WEZ +2. Es ist jetzt 04:58 Uhr.