Ankündigung

Einklappen
Keine Ankündigung bisher.

MySQL Query - MongoDB

Einklappen

Neue Werbung 2019

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

  • MySQL Query - MongoDB

    Guten Morgen,
    ich möchte mir eine Klasse erstellen, wo ich mein SQL Query in MySQL und später in MongoDB einsetzen kann.

    Sprich, eine Query Funktion für MySQL und MongoDB.


    Warum ich das möchte: ich möchte später nicht jeden Query in jeder meiner Klasse nochmal bearbeiten, wenn ich auf MongoDB umsteige.

    Auch ist der Grund, falls es später zuviele Daten gibt und MySQL dann dazu eine Ewigkeit braucht, bis dieser mir alle Informationen wieder gibt, die ich benötige. (Durch das richtige Setzen von INDEX kann MySQL eventuell die Anforderung bewältigen, aber bei Millionen von Daten wird das dann auch schwer). Sicher ist Sicher.

    zurzeit würde ich das ungefähr so machen:
    PHP-Code:
    class Database {
           
           
    //hier wird später entschieden, ob MySQL oder MongoDB (sprich JSON) eingesetzt werden soll
           
    public function sql_query($table$action$where) {

                  
    self::getMySQLAction($action);
                  
    self::MySQLQuery($table$action$where);
           }

           private function 
    getMySQLAction($action) {

                  switch(
    action) {
                         case 
    'insert':
                                
    $return 'INSERT INTO';
                           break;

                         case 
    'update':
                                
    $return 'UPDATE';
                           break;

                           
    //und so weiter;
                  
    }
           
                  return 
    $return;
           }

           private function 
    MySQLQuery($table$action$where) {

                  
    //Wandelt alles in einen normalen MySQL Query um und führt diesen dann aus
           
    }
    };

    $database = new Database();

    $sql_table 'User';
    $action 'insert'
    $where = array(
                
    'WHERE' => array(
                             
    'spalte' => 'spalte_1',
                             
    'inhalt' => 'blabla',
                             
    'operator' => '='
                              
    )
                  );
    $database->sql_query($sql_table$action$where); 
    Es ist verdammt Schade, das MongoDB keine JOINS bearbeiten kann. So muss man mehrere Querys schreiben.

    Gibt es Vor- und nachteile bei meinen Beispiel, wie ich es machen würde?

  • #2
    Das ist vermutlich deutlich komplexer als du denkst. Am besten du nimmst einen bestehen DBAL und einen ORM (damit kannst du die Abfragen komplett abstrahieren). Bei Laravel gibts da z.B. Eloquent und Moloquent
    Keine Ahnung, ob es noch weitere Projekte gibt, wo man so einfach zwischen SQL und NoSQL switchen kann.

    Kommentar


    • #3
      Bombastische Idee... wenn du dich auf den kleinsten gemeinsamen Nenner zwischen einer SQL Datenbank und einer NoSQL Datenbank beschränkst, was denkst du kommt da wohl am Ende raus?

      Jedenfalls nicht das:

      Zitat von Condor93
      Auch ist der Grund, falls es später zuviele Daten gibt und MySQL dann dazu eine Ewigkeit braucht, bis dieser mir alle Informationen wieder gibt, die ich benötige. (Durch das richtige Setzen von INDEX kann MySQL eventuell die Anforderung bewältigen, aber bei Millionen von Daten wird das dann auch schwer). Sicher ist Sicher.

      Kommentar


      • #4
        Man kann mit MongoDB nicht alles machen, was man mit RDBMS macht. Man macht es einfach komplett anders. Daher ist das Herangehen "die gleichen Queries so abstrahieren, dass sie später ohne große Anpassung auf MongoDB laufen" auch nicht zielführend.

        Du kannst in MongoDB keine Joins formulieren. Damit hast du auch keine ForeignKeyRelations und keine Constraints.

        Andersrum ausgedrückt: Wenn du eine relationale Datenbank so aufbaust, dass sie 1:1 auch in MongoDB funktionieren würde, ist deine relationale Datenbank (sehr) schlecht designt. Wenn du MongoDB so benutzt, wie du die relationale Datenbank benutzt hast, ist MongoDB (sehr) ineffektiv.

        Das was du vor hast geht nicht. Es sei denn, du hast ein wirklich einfaches Tabellenschema und deine Abfragen sind ebenfalls sehr einfach.

        Kommentar


        • #5
          Also von Anfang an gleich MySQL oder MongoDB benutzen.

          Ich würde das denn so machen (anhand eines Beispiels (Soziales Netzwerk))
          MySQL: User, Post, Bilderadresse, ...
          MongoDB: Chat

          Kommentar


          • #6
            desswegen sage ich immer wieder, Repository Design Pattern. In deiner Logik schreibst du keine SQL Statments, du hast ein Repository Interface der Methoden hat wie findByUsername() add() update() delete() das Repository liefert dir am ende immer Objekte zurueck , wenn du dann MongoDB verwenden willst, brauchst du an der logik nichts zu aendern sondern benuzt intern MongoDB Api

            https://github.com/BlackScorp/logd/b...ry/PDOUser.php

            hier habe ich zb eine PDOUserRepository, die ist nicht komplett, daten werden nur gelesen nicht gespeichert, die klasse implementiert das Interface.

            Meine geschaeftslogik ist in eine eigene Klasse gekapselt, diese nutzt das Interface https://github.com/BlackScorp/logd/b...ccount.php#L14

            Statt dem PDOUser kann ich dann eine MongoDBUser klasse erstellen und das interface implementieren, die Methoden befuellen und diese klasse an meine geschaeftslogik klasse uebergeben und schon werden daten in MongoDB gelesen

            Ich kann sogar eine fake(mock) klasse erstellen diese mit testdaten befuellen und automatisierte tests durchlaufen

            https://github.com/BlackScorp/logd/b...st.php#L30-L35 <-- dummy user erstellt
            https://github.com/BlackScorp/logd/b....php#L114-L123 <-- teste ob username vorhanden ist

            ich koennte sogar die Repositories kombinieren dass ich zb daten aus facebookapi auslese und dann daten in mongodb eintrage
            apt-get install npm -> npm install -g bower -> bower install <package> YOLO [URL]https://www.paypal.me/BlackScorp[/URL] | Mein Youtube PHP Kanal: [url]https://www.youtube.com/c/VitalijMik[/url]

            Kommentar


            • #7
              Zitat von rkr Beitrag anzeigen
              Man kann mit MongoDB nicht alles machen, was man mit RDBMS macht. Man macht es einfach komplett anders. Daher ist das Herangehen "die gleichen Queries so abstrahieren, dass sie später ohne große Anpassung auf MongoDB laufen" auch nicht zielführend.

              Du kannst in MongoDB keine Joins formulieren. Damit hast du auch keine ForeignKeyRelations und keine Constraints.

              Andersrum ausgedrückt: Wenn du eine relationale Datenbank so aufbaust, dass sie 1:1 auch in MongoDB funktionieren würde, ist deine relationale Datenbank (sehr) schlecht designt. Wenn du MongoDB so benutzt, wie du die relationale Datenbank benutzt hast, ist MongoDB (sehr) ineffektiv.

              Das was du vor hast geht nicht. Es sei denn, du hast ein wirklich einfaches Tabellenschema und deine Abfragen sind ebenfalls sehr einfach.
              Sag niemals nie. PostgreSQL insbesondere mit 9.4 kann beides. Und das NoSQL-Zeugs mit JSON sogar teilweise schneller als MongoDB.

              http://blogs.enterprisedb.com/2014/0...ce-benchmarks/

              Mit PG hast Du Du die Vorteiler beider Welten unter einem Dach. Was will man mehr?
              PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

              Kommentar


              • #8
                Zitat von akretschmer Beitrag anzeigen
                Sag niemals nie. PostgreSQL insbesondere mit 9.4 kann beides. Und das NoSQL-Zeugs mit JSON sogar teilweise schneller als MongoDB. Mit PG hast Du Du die Vorteiler beider Welten unter einem Dach. Was will man mehr?
                Das macht PG aber nicht zu einem (nicht DropIn-)Replacement für MongoDB, oder?
                Sharding?
                GridFS?
                MapReduce?
                Replication/HA (Level like MongoDB)?

                Kommentar


                • #9
                  Zitat von rkr Beitrag anzeigen
                  Das macht PG aber nicht zu einem (nicht DropIn-)Replacement für MongoDB, oder?
                  Sharding?
                  GridFS?
                  MapReduce?
                  Replication/HA (Level like MongoDB)?
                  Ich bin jetzt nicht so der Mongo-Experte, aber mit PG bekommst auch ne Menge hin in Richtung Replication (wahlweise synchron / asynchron),Sharding (plproxy) und so. Wo da Mongo besser ist weiß ich nicht. Beachte aber, daß man in PG alles unter einem Dach hat, also eine bekannt stabile SQL-DB und (seit vielen Jahren, länger als es MongoDB und Co gibt) auch NoSQL-Krams. Siehe HSTORE als Key-Value-Datentyp.

                  Und falls man wirklich auf Dinge wie MongoDB setzen will: via FDW (Foreign Data Wrapper) kannst auch von PG aus auf z.B. MongoDB zugreifen.

                  http://talks.bitexpert.de/unkonf2014-postgres-nosql/#/
                  PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

                  Kommentar


                  • #10
                    FDW finde ich persönlich sehr interessant. Schöne Ausführung!

                    Kommentar


                    • #11
                      Mh, da überlegt man sich ja immer mehr zu PgSql zu wechseln. Vorallem da man hier auch noch gratis die entsprechend komplexeren Queries gebastelt kriegt

                      Kommentar


                      • #12
                        Ich habe mir leider über die Jahre eine riesige mysql-basierte Datenbasis angelacht. Zudem fehlt mit unter PG noch ON DUPLICATE KEY UPDATE. Bastel zuhause gerade etwas mit PG rum.

                        Kommentar

                        Lädt...
                        X