[OOP] Datenbankeinträge in Objekte speichern?

Einklappen
X
 
  • Filter
  • Zeit
  • Anzeigen
Alles löschen
neue Beiträge

  • [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

  • #2
    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 ... :-)
    Mein PHP Blog

    Kommentar


    • #3
      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.

      Kommentar


      • #4
        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.
        Mein PHP Blog

        Kommentar


        • #5
          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.

          Kommentar


          • #6
            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.

            Kommentar


            • #7
              Original geschrieben von PHP-Desaster
              Oder einen objektorientierten, durch Caching ähnlich fixen Weg,
              Und diese Aufgabe würdet ihr einem ORM übergeben?

              Kommentar


              • #8
                <<
                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

                Kommentar


                • #9
                  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

                  Kommentar


                  • #10
                    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.

                    Kommentar


                    • #11
                      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

                      Kommentar


                      • #12
                        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

                        Kommentar


                        • #13
                          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

                          Kommentar


                          • #14
                            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

                            Kommentar


                            • #15
                              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

                              Kommentar

                              Lädt...
                              X