PHP 5 データオブジェクト (PDO) 抽象化レイヤーと Oracle_PHP チュートリアル-PHPチュートリアル-php.cn

PHP 5 データオブジェクト (PDO) 抽象化レイヤーと Oracle_PHP チュートリアル

WBOY

リリース： 2016-07-20 11:07:20

オリジナル

817 人が閲覧しました

PHP DataObject (PDO) データ抽象化レイヤーの元の developer では、Oracle での実行に焦点を当てて、抽象化レイヤーについて簡単に説明します。 PHP が必要: 5.0
その他が必要: Oracle 8 以降のクライアントライブラリ
PDO for Oracle (Windows) をダウンロード: php_pdo.dll、php_pdo_oci.dll
Oracle 用 PDO をダウンロード (Unix): pdo、pdo_oci
PDO の概要
PHP は主にボランティアプロジェクトです。定期的な「コア」開発者は数名いますが、フルタイムで有給で PHP の開発に取り組んでいる人はいません。それに加えて、私たちが世界の異なる地域に位置しているという事実もあり、長期的な発展を調整することがいかに難しいか想像できるでしょう。したがって、PHP は主に個人的な短期的なニーズに基づいて開発されています。その理由もさまざまで、実験のため、または「明日提出する仕事があるから」という場合もあります。これにより PHP は各段階で改善されることがよくありますが、長期的には完全性に欠けます -
データベースチュートリアル拡張機能はその重要な例です。さまざまなデータ拡張機能 (oci、
mysql、postgresql、mssql など) の間には、実際にはまったく一貫性がありません。また、場合によっては、これらの拡張機能内でも一貫性がまったくありません。これらの拡張機能のほぼすべては、基礎となるデータベース API に密接に結び付けられた異なるコードを使用して、同じ種類のタスクを実行します。そして、私たち (PHP コア開発者と拡張機能開発者) の人員は非常に限られているため、コードの保守がより困難になり、PHP にとって大きな問題が生じます。 PHP の人気と成功の高まりを受けて、主要な PHP データベース拡張機能の管理者がドイツで開催された LinuxTag 2003 カンファレンスに出席し、PHP の将来について意見を交換しました。 PHP 開発のランダム性について議論する際、私たちは PHP でのデータベースアクセスのいくつかの目標を特定しました:
・軽量で、明確で、便利な API を提供する
・さまざまな RDBMS ライブラリの共通機能を統一するが、より多くの
Advanced 機能を除外しない。・PHPスクリプトを介して、オプションでより高度な抽象化/互換性を提供します。
私たちがこの PHP Data Objects (PDO) の概念を思いついたのは、
Zend Engine 2 (PHP 5 のコア) の高度なオブジェクト指向機能を活用して、この API のパフォーマンスを向上させたいと考えたからです。 PHP のデータ抽象化レイヤーの概念はまったく新しいものではありません。Google クエリ
「PHP データベース抽象化」では、約 83,200 件の一致が見つかります。これは多くの PHP 開発者にとってほぼ夢の実現ですが、これが実現したのは API が不完全だったからでもあります。本当に重要なことを行うためにサードパーティの抽象化レイヤーを使用しようとしたことがある場合は、通常、抽象化レイヤーが目の前の仕事には強力すぎるように設計されているか、使用する前に多くの学習が必要であることがわかります。、またはインターフェースの速度が遅く、データベース独自の API に到達するためにマルチレイヤースクリプト関数を介してパラメーターを呼び出す必要がある場合、通常は上記の 2 つの症状が存在します。なぜこれらの抽象化レイヤーにこの問題が発生するのでしょうか？これらの抽象化レイヤーは、常に多すぎるタスク、場合によっては不可能なタスクを達成しようとします。私たちは実用性を目指し、最も一般的なデータベース API 機能のいくつかに基づいて、PDO ドライバープログラムが製品固有の機能を通常の拡張機能として公開できるようにすることにしました。なぜPDOを使うのか？データベース抽象化拡張機能に関する噂を聞いたことのあるほとんどの人は、すぐに PDO の拡張機能について疑問に思うでしょう。SQL を分析して、対応するバックエンド方言に変換したいのでしょうか?機能 X や機能 Y などをどのように処理するかなど。したがって、PDO ではこれについてまったく心配していないと聞いて驚かれるかもしれません。それを可能にする唯一の方法は、最も低い共通性基準に制限することであるため、すべてを完全に統一するつもりはありません。
PDO がモノリシック抽象化レイヤーではない場合、PDO の使用を検討すべき理由は他にありますか?
・パフォーマンス。 PDO は、既存のデータベースの拡張における成功と失敗について最初から学びました。 PDO のコードはまったく新しいため、PHP 5 の最新機能を活用するためにパフォーマンスをゼロから再設計する機会があります。
・能力。 PDO は、RDBMS の固有の機能に簡単にアクセスできるようにしながら、基盤として共通のデータベース機能を提供するように設計されています。
・シンプル。 PDO は、データベースの操作を簡単にするように設計されています。 API はコードに強制的に組み込まれることはなく、各関数呼び出しが何を行うのかを明確にします。
・実行時に拡張可能。 PDO 拡張機能はモジュール式であるため、PHP プログラム全体を再コンパイルまたは再インストールすることなく、実行時にデータベースバックエンドのドライバーを読み込むことができます。たとえば、PDO_OCI 拡張機能は、PDO 拡張機能の代わりに Oracle Database API を実装します。 MySQL、PostgreSQL、ODBC、Firebird 用のドライバーもあり、さらに多くのドライバーが開発中です。
PDO を、PEAR DB や ADODB などの他の一般的に使用される抽象化レイヤーとどのように比較するかを知りたい場合があります。 PDO は、API とパフォーマンスの両方の点で他の一般的な抽象化レイヤーよりも軽量ですが、PEAR MDB 2 抽象化レイヤーの多数の問題を処理するために使用されるものなど、データベースバックエンド全体での均一性を提供するという点ではそれほど優れていません。