Ankündigung

Einklappen
Keine Ankündigung bisher.

DB-Modell in OOP richtig aufbauen

Einklappen

Neue Werbung 2019

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

  • DB-Modell in OOP richtig aufbauen

    Ich bin zwar gerade ziemlich verwirrt, versuche aber trotzdem mal mein anliegen einigermaßen auf den Punkt zu bringen.

    Ich versuche gerade ein eigenes kleines Framework zu schreiben dass mir einige standartabläufe abnimmt. Nun bin ich an dem Punkt angekommen wo ich mir überlegt habe ob es nicht Sinn macht für die Datenbank ebenfalls einige standartabläufe zu automatisieren. Zum Beispiel die komplizierteren Selects in Methoden zusammenzufassen. Doch wie baut man sowas auf?

    Nun zerbreche ich mir darüber schon seit Tagen den Kopf. Wie man sowas aufbaut ohne wieder irgendwann wieder in einer sackgasse zu landen und alles wegwerfen zu müssen (Hatte schonmal eine DB-Klasse die aber irgendwann zu komplex und dadurch aufwendiger als der SQL-String selbst wurde).

    Jetzt habe ich mir folgendes überlegt:

    1. Erstellung einer klasse die sich um die verbindung und kommunikation zur DB kümmert (PDO-Object, Select-/Insert-Methode etc.).

    Soweit alles ok.

    2. Für jede DB-Tabelle eine eigene Klasse die die abgefragten Daten auffangen kann und somit einen schlüßigen Zugriff im PHP-Code ermöglicht.

    PHP-Code:
    class benutzer {

        private 
    $id;
        private 
    $vorname;
        private 
    $nachname;

    }
    class 
    benutzerrechte {

        private 
    $id;
        private 
    $bezeichnung;
        private 
    $beschreibung;


    Soweit ist für mich auch noch alles schlüßig, da aber jeder Benutzer mehrere Rechte haben kann, gibt es natürlich auch eine benutzer_zu_benutzerrechte tabelle die eine n:m beziehung herstellt. Jetzt währe aber folgende klasse aus meiner sicht vollkommen sinnfrei:

    PHP-Code:
    class benutzer_zu_benutzerrechte {

        private 
    $benutzer_id;
        private 
    $benutzerrechte_id;


    Jetzt überlege ich hin und her und komme auf keinen grünen zweig. Soll ich die Klasse benutzer_zu_benutzerrechte weglassen und stattdessen lieber eine weiteres attribut in der Klasse Benutzer hinzufügen dass dann mit instanzen der Klasse benutzerrechte befüllt wird?

    PHP-Code:
    class benutzer {

        private 
    $id;
        private 
    $vorname;
        private 
    $nachname;

        private 
    $benutzerrechte = array();


    Was wenn es dann noch weitere n:m verbindungen nach benutzerrechte gibt?

    Daher die Grundsatzfrage, wie stellt man ein DB-Modell sinnvoll in OOP dar? Gibt es dazu Tutorials/lektüren?

    Gruß
    Squall


  • #2
    Zum Beispiel die komplizierteren Selects in Methoden zusammenzufassen.
    Was auch immer das heißen mag - ein Tipp: Fang beim Aufruf an. Wie könnte das elegant aussehen, wenn Du Dir eine einigermaßen komplexe Query ausdenkst und diese mal aus Objekten/mit Objektzugriffen zusammensetzt? Wenn DU einen guten Weg findest, hast Du sozusagen gleich Dein Interface definiert.
    --

    „Emoticons machen einen Beitrag etwas freundlicher. Deine wirken zwar fachlich richtig sein, aber meist ziemlich uninteressant.
    Wenn man nur Text sieht, haben viele junge Entwickler keine interesse, diese stumpfen Texte zu lesen.“


    --

    Kommentar


    • #3
      Ich weiß nicht ob ich dich richtig verstanden habe aber bei mir kommt dann z.b. dass raus:
      PHP-Code:
      class benutzer {

          private 
      $id;
          private 
      $vorname;
          private 
      $nachname

          
      $benutzerrechte = array();
          
          
      findeBenutzerrechte() {
              
      $rechte = new benutzerrecht();
              
      $rechte $rechte->findeRechteEinesBenutzers($this->id);
          }
          
      }

      class 
      benutzerrecht {

          private 
      $id;
          private 
      $bezeichnung;
          private 
      $beschreibung;
          
          function 
      __construct($daten = array()) {
              if(
      count($daten) > 0) {
                  
      $this->id $daten->id;
                  
      $this->id $daten->bezeichnung;
                  
      $this->id $daten->beschreibung;
              }
          }
          
          function 
      findeRechteEinesBenutzers(benutzer_id) {
              
      $sql 'SELECT br.* FROM benutzerrechte AS br JOIN benutzer_zu_benutzerrechte AS bzr ON bzr.benutzerrechte_id=br.id WHERE bzr.benutzer_id =' $benutzer_id;
              
      $result $db->query($sql);
              
      $ergebnis $resukt->fetchAll();
              
      $return = array();
              foreach(
      $egebnis as $recht) {
                  
      $return[] = new benutzerrecht(recht);
              }
              return 
      $return;
          }
          

      Wenn wir jetzt annehmen dass die benutzerrechte auch zu einer anderen Tabelle eine n:m beziehung hat und diese wiederrum dass selbe, dann bläht sich der Parameter $benutzer->benutzerrechte dermaßen auf und ist voll mit arrays. Ich würde es aber bevorzugen mit Objekten zu arbeiten daher bin ich mir eben nicht sicher ob das der richtige weg ist.

      Kommentar


      • #4
        Zitat von nikosch Beitrag anzeigen
        Was auch immer das heißen mag.
        für mich klingt das ganze nach einem ORM. schau auf dem Links wie dort das ganze zusammengesetzt ist.

        Jedoch ich bin persönlich ein freund von eigener SELECT querys, ich denke es ist besser für eine anwendung einfach eine SQL query an den server zu schicken, anstatt die query dir erstmal zusammen zu basteln mit irgendwelchen methoden und danach erst die query an den server zuschicken. da ist halt ein zwischenschritt der eigentlich unnötig ist, meiner meinung nach

        MFG
        apt-get install npm -> npm install -g bower -> bower install <package> YOLO https://www.paypal.me/BlackScorp | Mein Youtube PHP Kanal: https://www.youtube.com/c/VitalijMik

        Kommentar


        • #5
          Hi,

          geht es dir bei diesem Thema um den Aufbau deiner Datenbankklasse, den deiner Abfragen oder nur um die Umsetzung des Datenbankdesigns in Klassen und Objekte?

          Chriz hatte mir mal den Tipp gegeben, mit Managern zu arbeiten, die sich um die Kommunikation mit der Datenbank kümmern. Die Datenbankabfragen verbannst du also aus den Klassen Benuzer und Benutzerrechte, um die Abhängigkeiten der Klassen von der Datenbank zu lösen.

          Natürlich ist es der Benutzer, der die Rechte hat und darum kannst du ihm diese auch als eine Eigenschaft zuweisen. In deinem Array speicherst du dann die Objekte der Klasse Benutzerrechte. Mit diesen Objekten kannst du dann ja prima weiterarbeiten.

          Ein paar weitere Tipps kannst du dir vielleicht noch aus diesem Thema holen: http://www.php.de/php-fortgeschritte...-auslesen.html.

          Gruß
          http://hallophp.de

          Kommentar


          • #6
            Zitat von BlackScorp Beitrag anzeigen
            Jedoch ich bin persönlich ein freund von eigener SELECT querys, ich denke es ist besser für eine anwendung einfach eine SQL query an den server zu schicken, anstatt die query dir erstmal zusammen zu basteln mit irgendwelchen methoden und danach erst die query an den server zuschicken.
            Wie schon erwähnt:

            Zitat von Squall Beitrag anzeigen
            Hatte schonmal eine DB-Klasse die aber irgendwann zu komplex und dadurch aufwendiger als der SQL-String selbst wurde
            Mir geht es um dass Grundverständnis bei n:m beziehungen. Wie spiegeln sich solche im Code wieder? wo werden die dadurch referenzierten Daten gespeichert? usw.

            Edit: Lese mir jetzt erstmal das Thema durch das Asipak gepostet hat.

            Kommentar


            • #7
              du könntest ja statt komplizierten querys ein view anlegen mit dem komplizierten query und dann im code die query vereinfachen. ungefair so:

              im phpmyadmin folgende query
              PHP-Code:
              CREATE VIEW user_has_rights AS
              SELECT br.* ,bzr.benutzer_id as user_id FROM benutzerrechte AS br JOIN benutzer_zu_benutzerrechte AS bzr ON bzr.benutzerrechte_id=br.id 
              dann brauchst du im code nur noch

              PHP-Code:
              SELECT FROM user_has_rights WHERE user_id $user 
              apt-get install npm -> npm install -g bower -> bower install <package> YOLO https://www.paypal.me/BlackScorp | Mein Youtube PHP Kanal: https://www.youtube.com/c/VitalijMik

              Kommentar


              • #8
                @Blackscorp
                Über Views bin ich bei meinen Recherchen auch gestoßen, allerdings muss ich zugeben das Prinzip dahinter nicht ganz verstanden zu haben und habe es deswegen noch nach hinten geschoben. Vielleicht verstehe ich es ja wenn ich es später nochmal durchlese.

                @Asipak
                Es geht um die Umsetzung des Datenbankdesigns in Klassen und Objekte und genau diesen Denkanstoß habe ich gebraucht. Das Prinzip mit den Managern hört sich ganz sinnvoll an. Darauß resultiere ich dass zu jeder DB-Tabelle die auch etwas physisches darsetellt, ein Objekt existiert dass sich auch nur mit diesem Objekt befasst und nicht damit wie es befüllt wird. Die Manager kümmern sich dann um die Datenbeschaffung und verarbeitung.

                Wenn keiner wiederspricht, bin ich wohl auf dem richtigen weg. Ich werde dann erstmal ein bisschen damit rumspielen und mich dann wieder zurückmelden

                Danke erstmal

                Kommentar


                • #9
                  das prinzip von views, könnte man so verstehen, dass du eine SQL query als eine tabelle abspeicherst, jedoch im code das view wie eine tabelle verwenden kannst. das view bezieht sich jedesmal aus anderen tabellen. d.h im eigentlichen view brauchst du keine daten einzufügen oder bearbeiten, das machste in den tabellen aus dem sich das view bezieht. das view wird auch dann nur die spalten besitzen, die du in der selectanweisung angesprochen hast. alle anderen spalten aus den beziehenden tabellen, werden ignoriert.

                  noch eine kleine nebensache. verwende InnoDB als engine und verwende Foreign Keys mit ON DELETE/UPDATE CASCADE befehl. ich hatte früher mal probleme dass wenn ich zb ein user gelöscht habe, so musste ich auch aus der tabelle rights die rechte entfernen und alle anderen dinge , die der user gemacht hat und was in die tabelle eingetragen wurde. nun brauche ich den user einfach zu löschen und alles was zu dem user dazugehört, wird automatisch gelöscht. d.h du brauchst dich dann im code nur darum zu kümmern wohin, was reinkommt, die views generieren dir das , was du tatsächlich am ende anzeigen willst, und wenn sich ein datensatz ändert, so wird es mit CASCADE automatisch in allen tabellen mitübernommen.
                  apt-get install npm -> npm install -g bower -> bower install <package> YOLO https://www.paypal.me/BlackScorp | Mein Youtube PHP Kanal: https://www.youtube.com/c/VitalijMik

                  Kommentar


                  • #10
                    Views verführen allerings zum lazy Umgang mit Tabellen und Joins. Eine Query mit echten JOINS dürfte in den meisten Fällen performanter sein.
                    --

                    „Emoticons machen einen Beitrag etwas freundlicher. Deine wirken zwar fachlich richtig sein, aber meist ziemlich uninteressant.
                    Wenn man nur Text sieht, haben viele junge Entwickler keine interesse, diese stumpfen Texte zu lesen.“


                    --

                    Kommentar


                    • #11
                      Zitat von nikosch Beitrag anzeigen
                      Views verführen allerings zum lazy Umgang mit Tabellen und Joins.
                      sind wir nicht alle ein wenig lazy? ich meine was er am anfang vorhatte (ORM) ist doch auf für lazy und nicht besonders performant. muss man sich halt überlegen, entweder views oder mit methoden einen sql string zusammenbasteln.. programmierer sind lazy
                      apt-get install npm -> npm install -g bower -> bower install <package> YOLO https://www.paypal.me/BlackScorp | Mein Youtube PHP Kanal: https://www.youtube.com/c/VitalijMik

                      Kommentar


                      • #12
                        Sorry wenn ich hier in die Views diskussion eingreife, aber ER hat doch noch eine Rückfrage zum Manager Modell.

                        Ich habe jetzt meine Klassen benutzer und benutzerrechte die jeweils auch über einen Manager verfügen und finde dass bissher sogar richtig super (Ein großes dankeschön erstmal an dieser Stelle).

                        Jetzt bin ich an dem Punkt angekommen wo ich die n:m verbindung herstellen möchte, daher die Frage "wie".

                        1. Ich erstelle in beiden Managern ein Attribut, sowie eine dazugehörige Funktion, die den Inhalt der anderen Tabelle holen und speichern kann.
                        2. Ich erstelle in der eher Relevanten Klasse, in meinem Fall der benutzer, ein attribut benutzergruppe und eine funktion die diese herausfindet.

                        Beim schreiben des Beitrags ist mir der geistesblitz gekommen, dass Punkt 1 sinnvoller ist, da ich ja auch mal nach allen benutzern einer bestimmten rechtegruppe suchen möchte. Da aber der nächste Dumme vielleicht über diesen Beitrag stollpert habe ich jetzt trotzdem mal gepostet.

                        Dennoch habe ich aber noch eine Frage da ich in besagtem Beitrag von Asipak etwas über die verwendung von Schleifen gelesen habe.

                        Zitat von Chriz Beitrag anzeigen
                        Nur: du führst jetzt in einer Schleife Datenbankabfragen durch, das ist schlecht.
                        Ist es generell schlecht oder fallbedingt schlecht?

                        Ich glaube ich könnte den ganzen Tag selbstgespräche führen . Natürlich ist es besser immer nur dass zu holen was ich aus der DB brauche. Aber wenn ich auf der einen Seite (z.b. benutzer) so ziemlich alles hole, werde ich höchstwahrscheinlich auch auf der anderen Seite (benutzerrechte) alles brauchen. Somit währen 2 DB-Abfrage sinnvoller die einfach alles holen, statt einem JOIN oder vielen SELECT´s die nur das holen was ich brauche.

                        Falls ich mit irgendwas unrecht haben sollte oder noch ergänzungsbedarf herscht könnt ihr euch natürlich gerne zu Wort melden

                        Kommentar


                        • #13
                          Es ist generell keine gute Idee, Datenbankabfragen in einer Schleife auszuführen. Der Performance wegen.

                          Wie du die Relationen unter den Instanzen organisierst, wurde ja auch schon in dem verlinkten Thema diskutiert.
                          Bin mir jetzt aber nicht sicher, ob du dazu jetzt noch eine Frage hast oder ob du dir diese schon selbst beantworten konntest.
                          Beim schreiben des Beitrags ist mir der geistesblitz gekommen, [...]
                          ...
                          http://hallophp.de

                          Kommentar


                          • #14
                            sind wir nicht alle ein wenig lazy?
                            Ich meinte das durchaus kritisch. Views enthalten bestimmte Kombinationen von Feldern, die vielleicht gar nicht im Ergebnis benötigt werden. Gerade gejointe Views sind sehr schnell mal sehr langsam.
                            --

                            „Emoticons machen einen Beitrag etwas freundlicher. Deine wirken zwar fachlich richtig sein, aber meist ziemlich uninteressant.
                            Wenn man nur Text sieht, haben viele junge Entwickler keine interesse, diese stumpfen Texte zu lesen.“


                            --

                            Kommentar


                            • #15
                              Sagen wir es mal so, aller Anfang ist schwer, ich muss mir jetzt die ganze bissherige denkensweise abgewöhnen, um dieses System zu verwenden.

                              Bisher hatte ich eine DB-Klasse die die Daten aus allen Tabellen besorgt hat. Diese wurden dann in Objekte gelegt und weiter verarbeitet. Dadurch dass sich Projekte ändern war ich dann zeitweise gezwungen mal fehlermeldungen in die Benutzer-Klasse abzulegen und diverse andere absurditäten.

                              Da das ganze jetzt aber etwas mehr Struktur bekommen soll und ich es zum ersten mal auch über einen längeren Zeitraum verwenden möchte, ist dass nunmal ein nötiger Schritt.

                              Kommentar

                              Lädt...
                              X