タグ

pdoに関するjustoneplanetのブックマーク (7)

  • MySQL を PDO で使うときは ATTR_EMULATE_PREPARES を設定しよう : DSAS開発者の部屋

    「DSAS for Social を支える技術」 というネタでadvent calendar に挑戦します。 methane です。 PDOで MySQL を使うときは、みなさん $stmt = $con->prepare("..."); して $stmt->execute($values); とかしてプリペアドステートメントを利用されていると思います。 実は、このプリペアドステートメント、パフォーマンス的にはあまり良くありません。1つのクエリを実行するために、プレースホルダ付きのクエリを投げた後に、それに値をバインドして実行するコマンドを投げるので、1回のクエリを実行するのに2往復の通信が必要になるのです。 プリペアドステートメントにはパフォーマンスの利点(同じクエリを何度も発行するときにDBサーバーがクエリの解析を繰り返さないでもすむ)というものと、SQLインジェクション対策になる(正

    MySQL を PDO で使うときは ATTR_EMULATE_PREPARES を設定しよう : DSAS開発者の部屋
  • PHPでデータベースを使う準備をする

    DBMSの機能を抽象化するメリットとしては、DBMSが変わっても同じように扱えるという点が挙げられます。共通の操作インターフェイスを通して、それぞれのDBMSを操作できるのです。この共通の操作インターフェイスを抽象化レイヤと呼びます(図2)。いわば、さまざまなDBMSの操作法の最大公約数のようなものです。 こうすることで、特定のDBMSに依存しないアプリケーションを作成できるようになります。ただし、抽象化レイヤを経由すると、DBMSのすべての機能を使えなくなる可能性があります。抽象化レイヤを使わないと、アプリケーションが特定のDBMSに依存することになりますが、クライアントライブラリ固有の機能をすべて使えるというメリットがあります。 PHPではこの抽象化レイヤとして、PHP Data Objects(PDO)、Open Database Connectivity(ODBC)、DBAの3種類

    PHPでデータベースを使う準備をする
  • PDOにおける一応の安全宣言と残る問題点

    8月18日にPHP5.3.7がリリースされました。このリリースにより、PDOのSQLインジェクションの問題が一応解決されたと判断しましたので、ここに「一応の安全宣言」を表明するとともに、残る問題について報告します。 PDOの問題とは何か 以前、ぼくがPDOを採用しなかったわけ(Shift_JISによるSQLインジェクション)にて報告したように、PHP5.3.5以前のPDOにはDB接続時に文字エンコーディングを指定する機能がないため、文字列リテラルのエスケープの際に文字エンコーディングをLatin1を仮定してしまうという問題がありました。この状態ですと、DBにShift_JISで接続している際に、SQLインジェクション脆弱性が混入しました。 ※ 実は、先のエントリの「追記(2010/07/01 22:20)」に紹介した方法で文字エンコーディングを指定できるのですが、ほとんど知られていないのと

  • ぼくがPDOを採用しなかったわけ(Shift_JISによるSQLインジェクション)

    補足 この記事は旧徳丸浩の日記からの転載です。元URL、アーカイブはてなブックマーク1、はてなブックマーク2。 備忘のため転載いたしますが、この記事は2010年7月1日に公開されたもので、当時の徳丸の考えを示すものを、基的に内容を変更せずにそのまま転載するものです。 補足終わり PHPのデータベース・アクセス・ライブラリPDOは、DB接続時の文字エンコーディング指定ができないため、文字エンコーディングの選択によっては、プレースホルダを使っていてもSQLインジェクション脆弱性が発生します。 追記(2011/06/19) ここに来て急にブクマが追加されはじめていますが、このエントリを書いてから状況が改善しています。PHP5.3.6(2011/03/17)にて、PDOでもデータベース接続の文字エンコーディングを指定できるようになりました。この版で、UNIX版のPHPでは解決しましたが、Win

    ぼくがPDOを採用しなかったわけ(Shift_JISによるSQLインジェクション)
  • PDO、PEAR::DB、MySQL関数の速度比較

    サーバー側の問題もあるので、毎回安定した処理結果は得られませんでしたが、大体上表のような結果になりました。 やはりネイティブ関数は速く、mysqli関数が一番速い結果になりました。 続いて同じくネイティブ関数のmysql関数が続き、その次にPDOという結果になりました。 PDOでは、プリペアドステートメントを用いてSQLを発行したため、2回目のSQLの発行ではキャッシュが効き、劇的な速さになっています。 一番遅かったのは予想通り、PEAR::DBでした。 ネイティブ関数よりも2〜3倍遅く、PDOよりも2倍近く遅い結果となりました。 PHP用アクセラレータを導入していなければ、PEAR::DBはもっと遅くなっただろうと考えられます。 まとめ PHP5を利用していて、DBの抽象化を行いたいのであれば、PEAR系のモジュールはやめてPDOにした方が良いと言えます。 単純なSELECT文の結果でさ

    PDO、PEAR::DB、MySQL関数の速度比較
  • PDOを使ってMySQLにSSL接続するパッチ

    こんにちは、熊谷です。 PHPからMySQLに接続するドライバはいくつかあります。MySQL拡張モジュールやMySQL改良版拡張モジュール、または抽象化レイヤであるPDOを通して。 最近はPDOを使用して接続するのが一般的なのかなと思ったりするのですが、symfonyを使用する場合、どうしても選択肢はPDOをになってしまいます。今までPDOを使っていて何の問題もなかったのですが、最近一つの問題に突き当たりました。それはMySQLへのSSL接続です。 MySQLは5.0からSSLでの暗号化接続が比較的簡単に行えるようになっています。SSLでの接続方法についてはいろいろ検索すると出てきますので、そちらを参照してください。 そんなMySQLのSSL接続ですが、現時点、PHPから行うにはMySQL改良版拡張モジュールしか対応していないようで、PDOではSSL接続を行うことが出来ません。ということは

    PDOを使ってMySQLにSSL接続するパッチ
  • PHP: 下位互換性のない変更点 - Manual

    Getting Started Introduction A simple tutorial Language Reference Basic syntax Types Variables Constants Expressions Operators Control Structures Functions Classes and Objects Namespaces Errors Exceptions Generators References Explained Predefined Variables Predefined Exceptions Predefined Interfaces and Classes Context options and parameters Supported Protocols and Wrappers Security Introduction

  • 1