php - mysql_connect - mysqli_query select*from

MySQLの拡張機能：

• 活発に開発されていない
• PHP 5.5（2013年6月リリース）では正式にdeprecatedれました。
• PHP 7.0（2015年12月リリース）から完全にremovedされました
  • つまり、 2018年12月31日現在、PHPのサポート対象バージョンには存在しません。 現在のところ、 セキュリティ更新プログラムのみを取得しています。
• OOインタフェースが欠けている
• サポートしていない：
  • ノンブロッキング非同期クエリ
  • プリペアドステートメントまたはパラメータ付きクエリ
  • ストアドプロシージャ
  • 複数のステートメント
  • トランザクション
  • "新しい"パスワード認証方法（MySQL 5.6ではデフォルトで5.7で必要）
  • MySQL 5.1のすべての機能

これは廃止予定であるため、コードを使用することで将来の証明が少なくなります。

プリペアドステートメントのサポートの欠如は、別の関数呼び出しで手動でエスケープするよりも、エラーの起こりにくい、外部データをエスケープおよび引用する方法がより明確であるため、特に重要です。

SQL拡張の比較を参照してください。

mysql_関数：

1. 期限が切れている - それ以上は維持されていない
2. 別のデータベースのバックエンドに簡単に移動できないようにする
3. 準備文をサポートしていないため、
4. プログラマーが連結を使用してクエリを作成し、SQLインジェクションの脆弱性を引き起こすようにする

より良い関数とコード構造が開発されたことを考えると、mysql_ *関数は（PHP 5.5以降）償却されました。機能が償却されたということは、性能とセキュリティの面でそれを改善するための努力がこれ以上行われないことを意味します。

さらに理由が必要な場合：

• mysql_ *関数はプリペアドステートメントをサポートしていません。
• mysql_ *関数はパラメータの束縛をサポートしていません。
• mysql_ *関数にはオブジェクト指向プログラミングの機能がありません。
• リストは続く...

最初に、私たちが全員に与える標準的なコメントから始めましょう。

share 。 彼らはもはや維持されておらずdeprecated 。 赤い箱を見ますか？ 代わりに準備文について学び、 PDOまたはMySQLiを使用してください。 この記事では、どちらを決定するのに役立ちます。 PDOを選択した場合、 ここでは良いチュートリアルです。

これを通過して文章で文章を説明してみましょう：

• 彼らはもはや維持されておらず、正式に廃止されました

  これは、PHPコミュニティがこれらの非常に古い機能を徐々にサポートしていないことを意味しています。 彼らはPHPの将来の（最近の）バージョンには存在しない可能性が高いです！ これらの関数を引き続き使用すると、遠く離れた場所でコードが壊れる可能性があります。

  新しい！ - ext / mysqlはdeprecated

  新しい！ ext / mysql はPHP 7で削除されました 。

• 代わりに、準備されたステートメント

  mysql_*拡張はプリペアドステートメントをサポートしていません。これは（とりわけ） SQLインジェクションに対する非常に効果的な対策です。 これは、MySQLに依存するアプリケーションに非常に深刻な脆弱性を修正し、攻撃者があなたのスクリプトにアクセスし、データベースに対して可能な限りのクエリを実行できるようにします。

  詳細については、「 PHPでSQLインジェクションを防止するにはどうすればよいですか？」を参照してください。

• レッドボックスを参照してください？

  mysql関数のマニュアルページに行くと、もう使用しないことを説明する赤いボックスが表示されます。

• PDOまたはMySQLiを使用する

  PDOはデータベースのやりとりに対する完全なOOPアプローチを提供し、 MySQLiはMySQL固有の改善です。

私は上記の答えが本当に長かったので、要約するとわかります。

mysqli拡張には多くのメリットがあります。これは、mysql拡張よりも重要な機能拡張です。

• オブジェクト指向インタフェース
• プリペアドステートメントのサポート
• 複数のステートメントのサポート
• トランザクションのサポート
• 強化されたデバッグ機能
• 組み込みサーバーのサポート

出典：MySQLiの概要

上記の答えで説明したように、mysqlの代わりにmysqliとPDO（PHP Data Objects）があります。

• APIはサーバサイドのプリペアドステートメントをサポートしています：MYSQLiとPDOでサポート
• APIはクライアントサイドのPrepared Statementsをサポートします：PDOのみがサポートします
• APIはストアドプロシージャをサポートしています：MySQLiとPDOの両方
• APIはマルチステートメントとすべてのMySQL 4.1+機能をサポートしています - MySQLiおよび主にPDOでサポート

MySQLiとPDOの両方がPHP 5.0で導入されましたが、MySQLはPHP 3.0より前に導入されました。注目すべき点は、MySQLはPHP5.xに含まれていますが、それ以降のバージョンでは非推奨です。

技術的な理由といえば、ごくわずかなものしかなく、極めて特定的であり、めったに使用されません。あなたの人生でそれらを使用することは決してありません。
たぶん私はあまりにも無知ですが、私はそれらのようなものを使用する機会がありませんでした

• ノンブロッキング、非同期クエリ
• 複数の結果セットを返すストアドプロシージャ
• 暗号化（SSL）
• 圧縮

もしあなたがそれらを必要とするならば、mysqlの拡張からもっとスタイリッシュでモダンなものに向かう技術的な理由は間違いありません。

それにもかかわらず、あなたの経験を少し難しくすることができる、技術的ではない問題もいくつかあります

• 最新のPHPバージョンでこれらの関数をさらに使用すると、廃止予定レベルの通知が発生します。彼らは単にオフにすることができます。
• 遠い将来、デフォルトのPHPビルドから削除される可能性があります。mydsql extがPECLに移行され、すべてのホスティング業者が数十年間働いていたサイトを失いたくないので、PHPをコンパイルすることができます。
• コミュニティからの強い抵抗。これらの正直な機能について言及すると、彼らは厳格なタブー状態にあると言われています。
• PHPの平均的なユーザーであるため、これらの関数を使用する考えは、エラーが発生しやすく、間違っている可能性があります。あなたが間違った方法を教えるこれらの数多くのチュートリアルとマニュアルのためだけです。関数そのものではなく、私はそれを強調しなければなりません。

この後者の問題は問題です。
しかし、私の意見では、提案された解決策はそれほど優れていません。
それは私にはあまりにも理想的な夢のようなすべてのPHPユーザーがSQLクエリを適切に一度に処理する方法を学ぶように思える。おそらくmysql_ *を機械的にmysqli_ *に変更して、そのアプローチを同じままにします。特にmysqliが準備文を使用すると、苦痛を伴う厄介なものになります。
ことは言うまでもありませんネイティブのプリペアドステートメントを保護するのに十分ではない SQLインジェクションから、そしてどちらmysqliのやPDOは、ソリューションを提供しています。

だから、この正直な拡張を戦うのではなく、間違った慣行と戦い、正しい方法で人々を教育することを好むだろう。

また、いくつかの虚偽または非重大な理由があります。

• ストアドプロシージャをサポートしていません（mysql_query("CALL my_proc");年齢を問わず使用しています）
• トランザクションをサポートしていない（上記と同じ）
• 複数のステートメント（それを必要とする人）をサポートしていない
• 積極的な開発の下ではありません（実際には何があなたに影響しますか？）
• オブジェクト指向インタフェースが欠けている（作成に数時間かかる）
• Prepared StatementsまたはParametrized Queriesをサポートしていない

最後の1つは興味深い点です。mysql extはネイティブのプリペアドステートメントをサポートしていませんが、安全のためには必要ありません。手動で処理されるプレースホルダを使用して準備されたステートメントを簡単に偽装することができます（PDOと同様）。

function paraQuery()
{
    $args  = func_get_args();
    $query = array_shift($args);
    $query = str_replace("%s","'%s'",$query); 

    foreach ($args as $key => $val)
    {
        $args[$key] = mysql_real_escape_string($val);
    }

    $query  = vsprintf($query, $args);
    $result = mysql_query($query);
    if (!$result)
    {
        throw new Exception(mysql_error()." [$query]");
    }
    return $result;
}

$query  = "SELECT * FROM table where a=%s AND b LIKE %s LIMIT %d";
$result = paraQuery($query, $a, "%$b%", $limit);

出来上がり、すべてがパラメータ化し、安全です。

しかし、大丈夫ですが、マニュアルの赤いボックスが気に入らなければ、選択問題が発生します：mysqliまたはPDO？

さて、答えは次のようになります：

• データベース抽象化レイヤーを使用する必要性を理解し、APIを作成する必要があることを理解していれば、mysqliは多くのmysql固有の機能を実際にサポートしているので、非常に良い選択です。

• PHPの大部分のように、アプリケーションコードの中で生のAPI呼び出しを使用している場合（本質的に間違った方法です）、PDOだけが選択肢です。この拡張はAPIだけでなく、半DAL、まだ不完全ですが、多くの重要な機能を提供しています。そのうちの2つは、PDOをmysqliと厳密に区別しています。

  • mysqliとは異なり、PDOはプレースホルダを値でバインドすることができます。これにより、動的に構築されたクエリは、いくつかの非常に乱雑なコードのスクリーンなしで実行可能になります。
  • mysqliとは異なり、PDOは常に単純な通常の配列でクエリ結果を返すことができますが、mysqliはmysqlndのインストールでのみ実行できます。

したがって、平均的なPHPユーザーで、ネイティブプリペアドステートメントを使用する際に頭痛の頭を払う必要がある場合は、PDOが唯一の選択肢です。
しかし、PDOも銀色の弾丸ではなく、苦労しています。
だから、私は、PDOのタグwikiのすべての一般的な落とし穴と複雑なケースの解決策を書いた

それにもかかわらず、エクステンションについて話しているすべての人は、ミスクリとPDOに関する2つの重要な事実を常に欠いています。

1. 準備された声明は銀色の弾丸ではありません。準備されたステートメントを使用してバインドできない動的識別子があります。パラメータの数が不明な動的クエリがあり、クエリ構築が困難な作業になります。

2. mysqli_ *関数もPDO関数もアプリケーションコードに記述してはいけません。 バインディング、ループ、エラー処理などの内部的な作業をすべて行い、アプリケーションコードをDRYでクリーンにするアプリケーションコードとの間に抽象化レイヤーを
   置くべきです。特に、動的クエリー構築のような複雑なケースの場合。

したがって、PDOまたはmysqliに切り替えるだけでは不十分です。そのコードにRAW API関数を呼び出す代わりに、ORM、クエリビルダ、またはデータベース抽象クラスを使用する必要があります。
逆に、アプリケーションコードとmysql APIの間に抽象レイヤーがある場合、どのエンジンが使用されているかは実際問題ではありません。廃止予定になるまでmysql extを使用して、抽象クラスを別のエンジンに簡単に書き直して、すべてのアプリケーションコードをそのまま残しておくことができます。

そのような抽象クラスがどうあるべきかを示すために、私のsafemysqlクラスに基づいたいくつかの例を以下に示します：

$city_ids = array(1,2,3);
$cities   = $db->getCol("SELECT name FROM cities WHERE is IN(?a)", $city_ids);

この1行と、PDOに必要なコード量を比較してください。
次に、生のMysqliが準備したステートメントで必要となるコードの狂った量と比較してください。エラー処理、プロファイリング、クエリのロギングが既に組み込まれて実行されていることに注意してください。

$insert = array('name' => 'John', 'surname' => "O'Hara");
$db->query("INSERT INTO users SET ?u", $insert);

これらの名前付きプレースホルダ、バインディング、およびクエリ定義のすべてにおいて、1つのフィールド名が6〜10回繰り返されると、通常のPDO挿入と比較してください。

もう一つの例：

$data = $db->getAll("SELECT * FROM goods ORDER BY ?n", $_GET['order']);

このような実用的なケースを処理するPDOの例はほとんどありません。
そしてそれはあまりにも言葉遣いであり、おそらく安全ではないでしょう。

だから、もう一度 - 生のドライバーだけではなく、初心者のマニュアルの愚かな例だけでなく、実際の問題を解決するのにも役立つ、抽象クラスです。

MySQLエクステンションは、3つのうち最も古いもので、開発者がMySQLとの通信に使用した元々の方法でした。この拡張機能は、PHPとMySQLの両方の新しいリリースで改善されたため、他のmysqli_PDOに有利にdeprecatedました。mysqli_ PDO

• mysqli_は、MySQLデータベースを扱うための「改良された」拡張機能です。新しいバージョンのMySQLサーバで利用可能な機能を利用し、機能指向とオブジェクト指向の両方のインタフェースを開発者に公開します。

• PDOは、これまで主要なデータベースアクセス拡張（MySQL、PostgreSQL、SQLite、MSSQLなど）に広まっていたほとんどの機能を統合したAPIを提供しています。このインタフェースは、データベース接続、クエリ、結果セット、および低レベル・ドライバーは、データベース・サーバーとの通信およびリソース処理を行います。多くのディスカッションや作業がPDOに入り、現代的でプロフェッショナルなコードでデータベースを操作する適切な方法と考えられています。

多くの理由がありますが、おそらく最も重要なのは、それらの機能は準備されたステートメントをサポートしていないため、安全でないプログラミング方法を奨励することです。プリペアドステートメントはSQLインジェクション攻撃を防ぐのに役立ちます。

mysql_*関数を使用する場合は、ユーザーが指定したパラメータを実行する必要がありますmysql_real_escape_string()。1つの場所だけを忘れた場合や、入力の一部しかエスケープしなかった場合、データベースが攻撃を受ける可能性があります。

PDOまたはで準備されたステートメントを使用mysqliすると、これらの種類のプログラミングエラーがより困難になるようになります。

（他の理由の中でも）入力データが確実に浄化されることははるかに難しいためです。パラメトリッククエリを使用する場合は、PDOまたはmysqliで行うように、リスクを完全に回避できます。

例として、誰かが"enhzflep); drop table users"ユーザー名として使うことができます。古い関数はクエリごとに複数のステートメントを実行できるので、その厄介なバグのようなものはテーブル全体を削除することができます。

mysqliのPDOを使用する場合、ユーザ名は最終的になり"enhzflep); drop table users"ます。

bobby-tables.com参照してください。