基本コード
先のコラムにも書いたのだが、共通パーツはそれぞれ奥が深い。
できるとしたら、それぞれ抽象化した機能を自己完結できるモジュールに分けて用意するのが妥当だろう。
オブジェクト指向言語用ならば、それはクラスファイルになるだろうし、前時代的な関数ライブラリなのかもしれない。
私が携わるプロジェクトは
が多い。
この数年はもっぱらPHPなのだが、相変わらずcgi形式でperlを用いるプロジェクトも多いのが現状。
ここでは一番頻度の高いPHPを中心にDB処理について考えてみる。
PHPでDBに接続するアプローチはいくつかある。
一番多いのは組み込み関数を用いるケースなのではないか。
PostgreSQLならばpgを接頭語に持つ関数群を用いる。
ただこのケースだと厄介なのが、DBが変わったときだ。
サイトの立ち上げ時のビジネスモデルは「極力お金をかけない」なんてのがあったりする。
そのときにイッパシのDBサーバとして機能提供してくれるのが、PostgreSQLやmySQLである。
ところが立ち上げ後に予想以上の反響があり、アクセスが集中したりデータ件数が爆発的に増加した場合に、やはり商用DBに変えたいなんてことはよくある話だ。
そんなときに組み込み関数で構成されたシステムは、少なくともDBアクセスする部分は全面的に改定する必要がある。
そんなことを念頭にすると、PEARやJDBCをかませてシステム構築をしたほうが、スケーラビリティは断然高まる。
共通パーツを用意しておく、ともなると、あるDBに依存さた組み込み関数で作成していると、違うDBが使われる場合に、使えないパーツになってしまう。
各DB用関数にあわせたパーツをそれぞれ作ることも可能ではあるが、保守が大変になる。
かといってPEARはすべての環境に入っているわけではない。
いやー難しいねってこと。
