Ankündigung

Einklappen
Keine Ankündigung bisher.

PDO - Beitrag

Einklappen

Unconfigured Ad Widget

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

  • PDO - Beitrag

    Geht um diesen Beitrag: http://php-de.github.io/jumpto/pdo/

    Nachdem es noch den einen oder anderen Input gab, verlagere ich das PN mal hier her. Ich steige beim letzten Beitrag mal vom Arne ein, die Punkte von davor sind soweit alle umgesetzt, falls noch etwas offen ist oder auffällt einfach hier anmerken. Danke!

    Zitat von Arne Drews
    Finde ich soweit gut.

    Anmerkungen:
    1. Bei der Wiederverwendung der Verbindung solltest Du evtl. für den einen oder anderen Laien den Funktionsaufruf mit reinschreiben.
    Ich könnte mir vorstellen, daß einige das // oder überlesen und meinen, daß das zusammengehört.

    2. Nur mal in den Raum geworfen: Wird das letzte Beispiel Multi Execute benötigt?
    Eigentlich zeigt das ja nur die Arbeitsweise von bindParam. Ich finde nicht, daß in der Wissensammlung Beispiele sein sollten mit dem Hinweis: "Aber bitte nicht so machen!".

    3. Dann eine Frage für mich zum Verständnis:
    Die PreparedStatements funnktionieren bei PDO meiner Meinung nach so gut, weil ich über bspw. bindParam() den Datentyp angeben kann.
    Das ist mir bei der Verwendung von execute( $array ) nicht möglich. Daher habe ich das eigentlich bisher nie verwendet.
    Wie zuverlässig erkennt er denn, welchen Datentyp ich übergebe?
    Debugging: Finde DEINE Fehler selbst! | Gegen Probleme beim E-Mail-Versand | Sicheres Passwort-Hashing | Includes niemals ohne __DIR__
    PHP.de Wissenssammlung | Kein Support per PN


  • #2
    Arne, danke zuerst mal. Dann im Detail:

    1. Das mit dem Beispiel geht klar, hatte vor das noch zu trennen (zwei Code-Blöcke), dann mach ich den Aufruf noch mit rein bzw. zeige bei der Klasse die Übernahme als privates property

    2. Das "Mulit-Execute" (blöder Name, fiel kein besserer ein ) Ich habe es daher reingenommen, weil es neben dem escaping ja einer der beiden Vorteile von P.S. ist bzw. als solches verkauft wird. Aber gefallen tuts mir auch nicht wirlich, mir fiel nur echt kein wirklich gutes Beispiel ein für ein konkretes ANwendungsszenario. Ev. hab ich mir damit bereits schon selbst die Antwort gegeben - sind vermutlich eher speziele Einzelfälle und dann findet man es auch in der Doku. Passt ,ich gebs raus.

    3. Array-Übergabe. Ich habe aus diesem Grund (Parameter nicht festmachbar) es zuerst nicht aufgenommen, aber finde es sieht von der Anwendung ganz parktisch muss ich sagen. Fachlich kann ich dir das leider nicht beantworten, müsste man mal bisschen Doku, google oder austesten. Irgend eine Regel/Logik muss es ja dafür geben.

    Ah, hier: http://php.net/manual/de/pdostatemen...ute-parameters
    Das nehme ich noch als Zitat mit auf!

    input_parameters An array of values with as many elements as there are bound parameters in the SQL statement being executed. All values are treated as PDO::PARAM_STR.
    Debugging: Finde DEINE Fehler selbst! | Gegen Probleme beim E-Mail-Versand | Sicheres Passwort-Hashing | Includes niemals ohne __DIR__
    PHP.de Wissenssammlung | Kein Support per PN

    Kommentar


    • Arne Drews
      Arne Drews kommentierte
      Kommentar bearbeiten
      Ok, also alles als String. Dann bleibt die Variante für mich nur zweite Wahl

  • #3
    Moin,

    Code:
    Dann eine Frage für mich zum Verständnis:
    Die PreparedStatements funnktionieren bei PDO meiner Meinung nach so gut, weil ich über bspw. bindParam() den Datentyp angeben kann.
    Das ist mir bei der Verwendung von execute( $array ) nicht möglich. Daher habe ich das eigentlich bisher nie verwendet.
    Wie zuverlässig erkennt er denn, welchen Datentyp ich übergebe?
    Bei Prepared Statements werden die Query und Parameter getrennt an die Datenbank übergeben, nothing new here I guess.
    Die Datenbank nimmt sich also die Query und wandelt die SQL-Syntax in c++ um, aus den verschiedenen Klauseln werden Objekt-Bäume gebaut, für die Parameter werden auch Objekte gesetzt.
    Beim Execute() werden den Parameter-Objekten dann die Werte übergeben, zum Ausführen des Vergleichs wird dann der Wert des Objekts abgefragt.

    Mein Fazit:
    Prepared Statements sind sicher, weil die Werte nicht in die Query reingesetzt werden, sondern erst dazu stoßen wenn die Query schon auseinander genommen wurde und den SQL-Kontext verlassen hat.


    Was mir in dem Artikel noch fehlt ist PDO::ATTR_EMULATE_PREPARES
    -> Native/Emulierte PS.
    Relax, you're doing fine.
    RTFM | php.de Wissenssammlung | Datenbankindizes | Dateien in der DB?

    Kommentar


    • #4

      Zitat von VPh
      Was mir in dem Artikel noch fehlt ist PDO::ATTR_EMULATE_PREPARES
      -> Native/Emulierte PS.
      Du meinst als Erwähnung? Von einer "fixen" Aufanahme in die $options hat mich das hier von jspit únd ChristianK abgehalten:

      http://www.php.de/forum/webentwicklu...68#post1265168
      Debugging: Finde DEINE Fehler selbst! | Gegen Probleme beim E-Mail-Versand | Sicheres Passwort-Hashing | Includes niemals ohne __DIR__
      PHP.de Wissenssammlung | Kein Support per PN

      Kommentar


      • #5
        Ah, ich wusste nicht, dass false als default gesetzt ist. Dann ist es wirklich nicht ganz so wichtig.
        Eine Erwähnung sollte es Wert sein, jupp.
        Ich kann auch heute Abend nochmal gucken, ich hatte da mal ein paar interessante Artikel, ob ich dir einen kleinen Text dazu schicken kann.
        Relax, you're doing fine.
        RTFM | php.de Wissenssammlung | Datenbankindizes | Dateien in der DB?

        Kommentar


        • #6
          Wobei, laut Doku:

          PDO::ATTR_EMULATE_PREPARES Enables or disables emulation of prepared statements. Some drivers do not support native prepared statements or have limited support for them. Use this setting to force PDO to either always emulate prepared statements (if TRUE), or to try to use native prepared statements (if FALSE). It will always fall back to emulating the prepared statement if the driver cannot successfully prepare the current query.
          Debugging: Finde DEINE Fehler selbst! | Gegen Probleme beim E-Mail-Versand | Sicheres Passwort-Hashing | Includes niemals ohne __DIR__
          PHP.de Wissenssammlung | Kein Support per PN

          Kommentar


          • #7
            Zitat von VPh
            Bei Prepared Statements werden die Query und Parameter getrennt an die Datenbank übergeben, nothing new here I guess.
            Richtig. Aber die Werte werden je Datentyp anders behandelt. also warum will ich alle Werte als String verarbeiten lassen, wenn es vielleicht keine sind.
            Daher bleibe ich lieber bei bindParam für jeden Value. Für das Argument, was gleich kommen wird: "Was machst Du, wenn Du viele Values hast?!", dafür würde ich dann einen Wrapper schreiben, der das binden mit den korrekten Datentypen übernimmt.
            Competence-Center -> Enjoy the Informatrix
            PHProcks!Einsteiger freundliche Tutorials

            Kommentar


            • #8
              Zitat von hausl Beitrag anzeigen


              Du meinst als Erwähnung? Von einer "fixen" Aufanahme in die $options hat mich das hier von jspit únd ChristianK abgehalten:

              http://www.php.de/forum/webentwicklu...68#post1265168
              meines wissens ist es allerdings so, dass EMULATE_PREPARES eben nicht per default auf false steht sonder leider auf true.
              https://bugs.php.net/bug.php?id=54638
              für die neueste Versionen von PHP könnte es vielleicht umgestellt worden sein hab aber dazu nichts gefunden und grad kein php installiert
              liebe Grüße
              Fräulein Dingsda

              Kommentar


              • #9
                Laut Changelog wurde das verhalten von ATTR_EMULATE_PREPARES bis heute nicht verändert.
                [URL="https://gitter.im/php-de/chat?utm_source=share-link&utm_medium=link&utm_campaign=share-link"]PHP.de Gitter.im Chat[/URL] - [URL="https://raindrop.io/user/32178"]Meine öffentlichen Bookmarks[/URL] ← Ich habe dir geholfen ? [B][URL="https://www.amazon.de/gp/wishlist/348FHGUZWTNL0"]Beschenk mich[/URL][/B].

                Kommentar


                • #10
                  Zitat von Arne Drews Beitrag anzeigen
                  Richtig. Aber die Werte werden je Datentyp anders behandelt. also warum will ich alle Werte als String verarbeiten lassen, wenn es vielleicht keine sind.
                  Warum sich darüber ein Kopf machen? Letztendlich spielt der Datentyp nur bei der Übermittlung zwischen Client und Server eine Rolle. Die Datenbank konvertiert diese Daten so oder so in das benötigte Format.(Wertebreich, Vorzeichen, Zeichensatz, Datum, Time usw...) Ausserdem sind die drei Parameter die dir PDO anbietet auch weit entfernt von dem was Mysql untersützt bei Prepared Statments. Das ist was die C API anbietet:

                  Code:
                  MYSQL_TYPE_TINY
                  MYSQL_TYPE_SHORT
                  MYSQL_TYPE_LONG
                  MYSQL_TYPE_LONGLONG
                  MYSQL_TYPE_FLOAT
                  MYSQL_TYPE_DOUBLE
                  MYSQL_TYPE_TIME
                  MYSQL_TYPE_DATE
                  MYSQL_TYPE_DATETIME
                  MYSQL_TYPE_TIMESTAMP
                  MYSQL_TYPE_STRING
                  MYSQL_TYPE_BLOB
                  MYSQL_TYPE_NULL
                  Und selbst das sind nicht alle Datentypen die Mysql kennt. Das ist meiner Meinung nach vergebene Mühe. Du sparst eine Handvoll Byte weil eine Ganzahl als Integer übertragen wird und nicht als Zeichenkette? *Schnarch*

                  Kommentar


                  • #11
                    Zitat von Arne Drews Beitrag anzeigen
                    Richtig. Aber die Werte werden je Datentyp anders behandelt. also warum will ich alle Werte als String verarbeiten lassen, wenn es vielleicht keine sind.
                    Gerade versucht, hier wird korrekt NULL in die DB geschrieben (DB-Defaultwert wäre ein anderer, nur sicherheitshalber erwähnt).

                    PHP-Code:
                    $sql "INSERT INTO `user` (`username`, `gender`) VALUES (:username, :gender)";
                    $stmt $pdo->prepare($sql);

                    $username 'Sarah';
                    $gender NULL;

                    $aParams = array(':username' => $username':gender' => $gender);
                    $stmt->execute($aParams); 
                    Debugging: Finde DEINE Fehler selbst! | Gegen Probleme beim E-Mail-Versand | Sicheres Passwort-Hashing | Includes niemals ohne __DIR__
                    PHP.de Wissenssammlung | Kein Support per PN

                    Kommentar


                    • #12
                      Ich wäre von meiner Seite durch, falls was auffällt, bitte einfach hier posten. Danke!

                      http://php-de.github.io/jumpto/pdo/

                      LG
                      Debugging: Finde DEINE Fehler selbst! | Gegen Probleme beim E-Mail-Versand | Sicheres Passwort-Hashing | Includes niemals ohne __DIR__
                      PHP.de Wissenssammlung | Kein Support per PN

                      Kommentar


                      • #13
                        Ich würde zu dem PDO Beitrag gerne noch etwas diskutieren - speziell zum Punkt "einfache Query ohne Parameter"

                        Ich stelle mal folgende Aussage in den Raum - würde gerne dazu eure Meiungen hören.

                        Man sollte unter PDO immer Prepared Statements verwenden, oder Backticks generell meiden. Tut man dies nicht verliert man einen der Vorteile von PDO, nämlich die theoretische Möglichkeit, relativ leicht das DBMS zu wechseln, da Backticks zB unter MS-SQL, Postgres, Oracle, etc .. per default nicht funktionieren. Somit entweder oder.
                        Debugging: Finde DEINE Fehler selbst! | Gegen Probleme beim E-Mail-Versand | Sicheres Passwort-Hashing | Includes niemals ohne __DIR__
                        PHP.de Wissenssammlung | Kein Support per PN

                        Kommentar


                        • #14
                          Für den Vorteil, das DBMS wechseln zu können, gebe ich Dir im Punkt Backticks recht!
                          PreparedStatements würde ich ebenfalls als grundlegend ansehen! Warum auf eine Möglichkeit verzichten, die SQL-Injection größtenteils schon verhindert und keinen verhältnismäßig größeren Aufwand für den Entwickler bedeuten?!
                          Competence-Center -> Enjoy the Informatrix
                          PHProcks!Einsteiger freundliche Tutorials

                          Kommentar


                          • #15
                            Man sollte unter PDO immer Prepared Statements verwenden
                            Ist bei Queries ohne Kontextwechsel doch nur unnötiger Overhead.

                            oder Backticks generell meiden.
                            Jo, würde ich so unterstützen. Vielleicht dazu noch paar Richtlinien zur Namensgebung von Tabellen und Spalten. 'am besten keine Sonderzeichen, keine reservierten wörter...'
                            Relax, you're doing fine.
                            RTFM | php.de Wissenssammlung | Datenbankindizes | Dateien in der DB?

                            Kommentar

                            Lädt...
                            X