PHP応用

ＰＨＰはサーバーサイドで実行させるスクリプトです。ですので、JavaScriptのようにリロードなしで画面を書き換える事はできません。しかし、サーバー側で処理するが故に、サーバー自身やサーバー側のローカルネットにしかないデーターベースへのアクセスが可能です。

なので、ＰＨＰはしばしば業務系・・・すなはち、遠方にある顧客からの注文を受けたり、遠方にある仕入先に発注したりする際に用いられます。ＰＨＰではデーターベースと連動して使うものだ、と言ってしまっても過言ではないでしょう。

応用編では、ＰＨＰプログラマとしてほぼ必須であるデーターベースと連動して使う方法について説明します。

データーベースへのアクセスをする時は、まずデーターベースへコネクトしなければなりません。ここでは、既にデーターベースがwebサーバー自身にインストールされている、またはwebサーバーからデーターベースサーバーへ接続可能な状況になっているものとして話を進めます。

ここでは、PostgreSQLかMySQLかのいずれかを使うものとして話を進めていきます。

・PosrgreSQLの場合

・MySQLの場合

MySQLでは引数にデーターベース名がありません。接続後に、mysql_select_db("データーベース名")で選択するか、あるいは、mysql_db_query("データーベース名","クエリー")関数を使って選択します。

ユーザーは事前に作成しておきます。MySQLの場合、

パスワードは、grant all privileges on *.* to ユーザー名@ホスト名 identified by 'パスワード' with grant option;という風にユーザー作成と同時に設定したかったのですが、この文を書いてる時点のバージョンのPHPでは、MySQL4.1以降の方式で暗号化されたパスワードに対応していません。なので、上記の例のように一旦パスワードなしでユーザーを作成してから、old_password句を用いて4.0以下と互換形式で暗号化されたパスワードを使うように指定します。

権限にはselectやinsertなどを指定しますが、all privilegesと書けば「全部」という意味になります。データーベース名、テーブル名の所も、*.*と書けば「全部のＤＢで全部のテーブル」という意味になります。ホスト名はwebサーバーがDBサーバーも兼ねてる場合はlocalhostとします。

PostgreSQLではパスワードはユーザー単位でpg_shadowというファイルで管理されています。また、pg_hba.confでローカルからパスワードなしてアクセス許可がされている場合は、PHPからの接続の際にもパスワードの指定が不要になります。ただし、セキュリティーの上あまりよろしくないので、PHPからPostgreSQLに接続するユーザーをあらかじめ作っておき、パスワードも設定しておきましょう。PostgreSQLでユーザーを作成し、パスワードを設定するには、

とします。ユーザーを作るだけなら、コマンドラインからcreateuserを使うという方法もあります。

データーベースサーバーにコネクトが成功すると、コネクションＩＤを返します。コネクションIDをprint 文で表示させると、Resource id #35みたいに表示されます。つまりTRUEです。失敗したときは、NULLが返りますのでFALSEです。なので、以下のようにしてエラー処理を作ります。

コネクトに成功した時の処理が特にない場合は、単にセミコロンのみを書いておいても良いですし、if (!($id=mysql_connect("ホスト名", "ユーザー名", "パスワード")))のように「偽だったら」という条件文にして、エラー処理のみを書くという手もあります。

データーベースを操作するためには、SELECTやINSERT、UPDATE等のステートメントを実行する必要があります。したがって、PHPプログラマーはデーターベースのSQL文についても熟知しておく必要があります。

しかしながら、この章ではステートメントそのものについては説明しませんので、別途このサイトにあるデーターベース入門やPostgreSQL入門を読んでおいてください。

ここでは、ステートメントの実行方法のみを説明します。

・PostgreSQLの場合

・MySQLの場合

idの指定は省略する事ができます。省略した時は、最後にコネクトしたデーターベースに対してクエリーが実行されます。データーベースが１つしかない、あるいは、主に接続するデーターベースが決まっている場合はidを省略しても大丈夫ですが、そのプロジェクトで将来的に複数データーベースに接続する可能性がある場合は、idを指定しておいた方が、後々の変更点が少なくて済みます。

ステートメントが失敗すると結果ＩＤ($result)にFALSEが入りますので、pg_errormessage($id)関数を使ってエラーの原因を表示させるようにすると、デバッグが楽になります。

例）$result値が偽ならエラーの原因を表示

ステートメントが成功すると、結果ID($result）が「真」になります。ここで、結果ID（$result）を使って変数に格納します。

・PostgreSQLの場合

・MySQLの場合

MySQLでは、いったんmysql_data_seekで "何行目のデーターを必要としているのか" を、ポインタを移動させてからオブジェクトに格納します。そのため、MySQLの方が１行程長くなります。

この例では、列名と同じ名前の変数に値を入れてます。こうしておくと、ソースの可読性が高まりますが、同じ名前の変数を別の用途で使いたい事もあるでしょうから、$DB_列名みたいにデーターベースから取り出した変数には特定の接頭語をつけておくと、バグの可能性が少なくなります。

データーをダイレクトに取り出す事ができます。これは、結果が数行に渡るわけではなく、たいてい１個だけの場合（合計値を得たい場合など）は、こちらの方が便利です。

・PostgreSQLの場合

・MySQLの場合

フィールドには、列名を指定できますが、列番号を指定する事もできます。（列番号の先頭は０です）

この関数は、行番号を「０」に固定して使う場合には便利です。たとえば、total値を得たい場合、得たい結果は０行目の０列目に決まっているので、pg_fetch_result($result,0,0)のように書くことができます。

ただ、結果が多い場合にこの関数を何度もコールしなければならず、また、データーベースから取り出した値が０や空文字だった場合に偽になってしまうため、エラーがほとんど起こらないであろう場所で、結果を１個だけ欲しい場合以外は使わない方が良いです。

・PostgreSQLの場合、

・MySQLの場合

この例では、$DB_data[0]には１列目、$DB_data[１]には２列目、$DB_data[２]には３列目………、の順に値が入ります。xxxx_fech_rowと、xxxx_fech_arrayの違いは、xxxx_fech_arrayの方は連想配列にも値がセットされるという点です。つまり、xxxx_fech_arrayを使った場合は、$DB_data["列名"]としても値が取り出せるようになるという事です。

もし、数字配列しか使う事ができないとしたら、後から仕様変更で取得する列が増えたり減ったりした場合、その都度列番号を変えなければなりません。「後からの仕様変更」これは、プログラマーにとって最も怖いものであり、頻繁に発生する事です。あとから取得する列が増えるか減るかした場合に、もし普通の配列としてデーターを取り出している箇所があると、取り出すカラムと変数の関係がズレてしまいます。なので、変数に代入している箇所全てを書き直さねばならないのですが、どうしても直し漏れが発生してしまいます。

なので、プログラムというものは、できる事なら後からの仕様変更でもバグが出にくい構造になってなくてはなりません。というわけで、xxxx_fech_rowよりも、 xxxx_fech_arrayを使った方が、添え字に直接列名を記述することができ、後から列が増えてもさほど影響のないプログラムになります。

※注意
fetch_arrayで連想配列を使う場合に注意しなければならないのは、大文字と小文字の扱いです。PostgreSQLではいくらCREATE文を大文字で書いても、内部では全部小文字として扱われますので、キーワードは小文字で指定しなければなりません。しかし、MySQLでは大文字と小文字を区別しますので、CREATEした通りの大文字小文字の組み合わせで指定しなければなりません。また、オラクルでは列名は全部大文字になります。

データーベースからデータを取得した後、データーの取得に使ったメモリを開放します。

・PosegreSQLの場合

・MySQLの場合

Ｃでは使ったメモリーは不要になれば開放するのが普通ですし、Perlでも特に常駐プロセスを作る際などは、使ったハンドルは随時解放するように作ると思います。しかし、PHPではこの手続きはさほど必要としません。それは、ＰＨＰがページ単位でブラウザに情報を表示させる事を主としているため、大抵の場合、メモリがあふれる程の巨大データーを扱う事もないし、まして、メモリに常駐して何かの制御を行う事も稀です。

なので、ＰＨＰでブラウザにデーターベースから取得した結果をを表示させる程度の目的であれば、メモリーを明示的に開放する必要はほとんどありません。なぜなら、プログラム終了時にPHPの方で自動的にメモリを開放するためです。実際、筆者の経験上pg_free_result関数を使わなかったせいでトラブルになった事はありません。

しかし、使ったメモリは必ず開放するという習慣はつけておかないと、ＰＨＰ以外の言語を扱う際に思わぬバグになったりしますので、なるべくpg_free_resultは入れておく方がベターです。pg_free_result_を省略するにしても、「大してメモリは消費してないし、プログラム終了時に自動的に開放されるので、あえて省略した」と、意味がわかった上で省略するようにしましょう。

・PostgreSQLの場合

・MySQLの場合

データーベースとのコネクトを閉じます。実際は、そのプログラムが終了した地点で自動的にクローズが行われるため、明示的にクローズする必要はありませんが、明示的にクローズした方が、データーベース処理の終了部を発見しやすくなり、ソースの可読性が高くなります。

８ビット～16ビット機が主流の時代からプログラムを作っていた人はよくわかっていると思いますが、昔はオープンしたファイルをクローズしないで終了してしまうと、データーが破損してしまう事がよくありました。というより、昔はファイルをクローズしないでプログラムが終了した場合、大抵ファイルが壊れました。BASICならINPUT PAST ENDが出てファイルが開けなくなるし、COBOLならエラー153が出てプログラムが停止してしまった事でしょう。

今はファイルをクローズしないと破損してしまうような言語はほぼないと思います。データーベースにしろファイルにしろ、今はプログラム終了時に言語（ランタイム）やＯＳの方でファイルを閉じてくれますから。とはいえ、苦難の道を歩んできた（？）８ビット機からのプログラマーとしては、開いているハンドルは最後にはクローズして終わらせたいです。

という事で、プログラムの最後にはpg_closeやmysql_closeを入れるようにしましょう。

PHP ＋ PosegreSQL（またはMySQL）が使える環境では、データーベースと連動したさまざまなインターネットアプリが、これまで以上に楽に作れるようになります。

今までCD-ROM等でパッケージ販売されていたソフトも、これからはどんどんＡＳＰ化してくることでしょう。