| ||||||||
| 1 2 次のページ | ||||||||
| データベース抽象化レイヤー | ||||||||
データベース抽象化レイヤーは、難しいと考えられているデータベースの変更をより簡単に行うことができます。しかし、抽象化レイヤーを使用していても、完全にデータベース間の依存性をなくすることは難しいことです。リスト1を見てみると、OracleとMySQLではストアドプロシージャの呼び出し方が異なることがわかるでしょう。Oracleでのストアドプロシージャの呼び出しはBEGINではじまりますが、MySQLではCALLで実行されます。 リスト1 //MySqlのストアドプロシージャこれはデータベース抽象化レイヤーを使用するときの欠点の1つです。もし抽象化レイヤーの目的がコードのポータビリティを保つことであると、プロシージャの呼び出しは当然一般化する必要があります。PDOではANSI SQLに厳格に従っており、プリペア文はすべてのデータベースはこの標準通りに理解するので一般化できますが、ストアドプロシージャの呼び出しはデータベースごとに異なります。 データベース抽象化レイヤーの主な利点は、同様のタスクを実行するためのコードの量を減らし、単純化することにあります。もしPHP 5.1のリリースを待てないのなら、ADOdbが最適な解となるでしょう。ポータビリティを重要視するのであれば、複雑なSQLのクエリを標準化するために相当な時間を使わなければならないことに注意しましょう。 ADOdbでOracleだけの機能を使用する場合や、特定のデータベースに制限された機能があるので、ポータビリティを確保することは簡単ではありませんし、現実的ではないでしょう。 | ||||||||
| ストアドプロシージャ/関数/インデックス/ビュー | ||||||||
Oracleのセキュリティ機能とデータ処理速度を利用するためには、Oracleデータベースに内蔵されたモジュールであるストアドプロシージャと関数を利用するのが最適です。OracleのPL/SQL言語やJavaで記述することができます。PL/SQLはCOBOLの時代から存在するプロシージャ用の言語で、比較的簡単に構文を理解することができるでしょう。ネイティブなOracleのように、コマンドを実行する前にコンパイルする必要がないので、パフォーマンスも改善されます。 データベースの方がPHPなどのスクリプト言語よりも巨大なデータを扱うのに適しているので、ビジネスロジックはできるだけストアドプロシージャで実装するべきです。プロシージャによって再利用が簡単になり、ビジネスロジックのカプセル化を行うこともできます。先にあげた大学同窓会のポータルでは、1つのプロシージャでページに表示するユーザの情報をすべて取得することができます。 また、プロシージャで使用される同じデータベースロジックが複数のページで必要なので、コードの再利用も促進されます。例えば、データベースが従業員の来週のスケジュールを返すプロシージャを持っていれば、クエリを発行し、日にちを調節し、データをフォーマットするということをプロシージャにパラメータを渡して呼びだすだけで済むようになります。 PHPからストアドプロシージャを呼びだす時は、ステートメントがまずパースされ、データがバインドされてから実行されます。一度パースされたステートメントに対して異なる変数をバインドして実行することもできます。 Oracleの関数はストアドプロシージャと同じような機能を持っていますが、関数内でOUT変数を使用することができません。関数は1つの値のみを返さなければなりません。ストアドプロシージャと関数を使用するもう1つの利点は、変数がバインドされることです。変数がバインドされるとSQL内で変数が利用されないので、SQLインジェクションが起きる心配がなくなり、プログラマもエスケープを気にする必要がなくなります。 | ||||||||
| 1 2 次のページ | ||||||||
書籍紹介PHPプログラマーズマガジン PHPプログラマーズマガジンは、PDF形式で読者の方にお届けするPHP言語(PHP: Hypertext Processor)専門誌です。 カナダMTA出版のphp|architect誌を日本語に翻訳し、独自の記事を加えて月刊でお届けしています。 発行:アシアル株式会社 価格:1,029円 | ||||||||
| ||||||||
| ||||||||
| ||||||||


