###前提・実現したいこと
PHPを学習中です。PHPのマニュアルを見ていたのですが、mysql_*系の関数が5.0以降では非推奨になり、その後7.0で廃止されたと書いてありました。たしかに、PDOはMySQL以外での知識を生かすために便利だったり、mysql_*系の関数自体が性能が低いことも考えられるのですが、mysql_*系の関数を廃止する具体的な理由とはどのようなものがあったのでしょうか？
よろしくおねがいします。

行動規範の内容に同意します

回答7件

ベストアンサー

憶測も交えながらの回答となります。

#機能面の問題
他の回答者様も言及してますが、
まずは機能面の問題が考えられます。

バインドメカニズムが利用できない(プリペアドステートメント非対応)
トランザクション機能が標準実装されていない(コマンドを投げれば不可能ではないですが・・・)
ストアドプロシージャを扱えない
MySQL5.1以降に導入された主要な機能が扱えない
オブジェクト指向非対応

などなど機能面の不足がありますが、
特に1つ目のバインドメカニズムが利用できないのはセキュリティ上致命的です。

そこはtakepieeeさんの掲示されているリンク先などが参考になると思います。
バインドメカニズムが利用できないと自前でエスケープをかけてあげる必要がでてきますので、その面でも不便となります。

開発状況の問題

m6uさんの掲示されているPHP公式マニュアルにも記載されていますが、MySQL系のモジュールのうち、
のみMySQL APIはVer5.xでは保守サポートのみ、Ver7.xからは保守も終了しています。

そんな状況のモジュールを、
PHP公式として利用できる状態のまま放置する方がまずいという考えもあるように思います。
(公式が廃止を決めたから保守を止めたという可能性もありますが)

#オブジェクト指向の導入上の問題
これは完全に憶測ですが、
MySQL APIの方の改修が滞ったのには、
PHPがオブジェクト指向をサポートを取り入れた流れを受けての影響もあるかなと思います。

PHP3.0以前から導入されていたライブラリにオブジェクト指向の機能を随時リリースするより、
新しいライブラリとしてオブジェクト指向のサポートを進めた方が開発・管理上の都合の良さがあったのではないでしょうか。

既存のライブラリを触って、
デグレさせるのはご法度という状況、
かつオブジェクト指向という方向性の異なる実装をサポートするよう回収するのは容易とは到底思えませんので。

それもありPHPのVer5.0を迎える時まで、じっくりライブラリ開発を進めていたのではないのかなと勝手に想像しています。

長々と書いてきましたが、
あっている確証はないのでこんな考え方もあるんだなという参考程度に。

投稿2016/12/20 13:00

編集2016/12/20 14:36

Panzer_vor

総合スコア1636

セキュリティ的なものだったと思います。
文字コード指定set_namesが危険、プレースホルダが使えない等です。
SQLインジェクション対策は勉強されているのであれば熟読したほうがいいと思います。

基準はIPAが作っていますので、参考までに。

安全なウェブサイトの作り方
http://www.ipa.go.jp/security/vuln/websecurity.html
安全なSQLの呼び出し方
http://www.ipa.go.jp/files/000017320.pdf

もし間違っていたらごめんなさい。

投稿2016/12/20 10:02

takepieee

総合スコア686

mysqlモジュールをPHP5.5から非推奨にした際の議論が下記URLで確認できます。

https://wiki.php.net/rfc/mysql_deprecation

上記URL「Why?」の内容を読む限り、他の方も挙げられているようなセキュリティの問題や、コードベースが古すぎてメンテナンスが大変すぎる、などが主なところのようですね。

PHP同梱ではなくなってPECLモジュールに格下げになったのは、メジャーバージョンアップのタイミングに合わせて整理したということでしょう。mysqlに限らず、十分なメンテナンスができていないようなモジュールはマイナーバージョンアップでいったん非推奨とし、次のメジャーバージョンアップで本体から外すのが最近の流れのようです。下記URLも合わせてご確認ください。

投稿2016/12/29 07:26

編集2016/12/29 07:29

hnw_

総合スコア51

単純に新バージョンのMySQLに対応したmysqliを作ったからです。

PHPは後方互換を重視する文化で、
RFCというページを作って過半数の賛同を得られないと実装出来ません。
参考URL： PHP7の内部実装から学ぶ性能改善テクニック - @hnw氏

実際にRFCを見ましたが書いてないですね…
なのでなぜmysqli関数を作って乗り換えたのかという直接的な理由は分かりません。

ただ、その背景にそのような文化があり、mysqlモジュールを破壊的な改修して対応させるよりも、
mysqliという新モジュールを定義して乗り換えるようにアナウンスしたという経緯があると推測されます。

投稿2016/12/21 05:00

編集2016/12/21 05:02

miyabi-sun

総合スコア21238

PHP: どの API を使うか - Manual
http://php.net/manual/ja/mysqlinfo.api.choosing.php
……にある機能比較表がわかりやすいです。

PHP: Overview - Manual
http://php.net/manual/ja/mysqli.overview.php

The mysqli extension has a number of benefits, the key enhancements over the mysql extension being:
Object-oriented interface

Support for Prepared Statements

Support for Multiple Statements

Support for Transactions

Enhanced debugging capabilities

Embedded server support

サーバーサイドのプリペアドステートメントが使えるようになった、ストアドプロシージャをサポートした、複数ステートメントを一度に実行できるようになった、トランザクションに対応してロールバック/コミットできるようになった、MySQL 5.1移行の新機能に対応している、オブジェクト指向で開発できる、などなど。

投稿2016/12/20 10:09

退会済みユーザー

総合スコア0

個人的な見解ですが
アプリケーションとコアレベルで連携をすると、アプリ側がバージョンアップしたときに
プログラム側が汎用性を保ったまま吸収することができないからではないかと。
多少パフォーマンスを犠牲にしても汎用性を保つためにPDOが利用されるのもその流れかと。

投稿2016/12/20 11:47

yambejp

総合スコア117244

セキュリティ上バインドメカニズム,プレースホルダーが有用といきなり言われてもと感じている場合だけ参考にしてください。
たとえば
SELECT カラム,... FROM テーブル名　WHERE カラム=' (ユーザ入力値)';
を実行するシステムを想像してください。
ここで、(ユーザ入力値)を悪意をなして、「1';DROP TABLE テーブル名; SELECT '」
を入力したとします。
そうすると、もしも、入力値を何もチェックしていないと、
SELECT カラム,... FROM テーブル名　WHERE カラム='１’；
DROP TABLE テーブル名;
SELECT '’；
の３個のSQLをが実行されてしまします。
そういう意味で、自動的に複数のSQLになったりすることを防止するメカニズムが
プログラムの記述いかんにかかわらず行われる副作用が、バインドメカニズムやプレースホルダや
に組み込まれているので、より安全性が高いと言うことができます。