mdb2で処理された行数を知る

2007/01/29 | その他PEAR全般

mdb2でデータベースに対してクエリを投げる方法は2つある。それはqueryメソッドとexecメソッドだ。これらは用途によって使い分ける必要がある。

queryメソッド
SELECTする際にはこちらを使用する。戻り値はエラーオブジェクトかMDB2_Resultオブジェクト。

execメソッド
データ行に影響を与える場合に用いる。戻り値はエラーオブジェクトか影響を及ぼした行数(いわゆる「affected rows」というやつ)。

以前はqueryメソッドしか使ってなかったので反省の意味も込めてメモ(affected rowsを取得する必要がなければqueryメソッドだけでも大丈夫ではあるのだけれど・・・)。

Pagerとmod_rewriteで

2007/01/14 | その他PEAR全般

Pagerがきわめて有効だということがわかった。
次はPagerをPATH_INFOに対応させる方法の検討。
せっかく「mojavi」「mod_rewrite」でURLの短縮に成功したのだから、次はこれらの中でPagerを使うことで、どんどん開発が簡単になる(そしてSEO的にも優しい)。
しかしPagerをフツーにつかっていてはPATH_INFO的な使い方はできない。デフォルトでは指定されたURLの末尾に?pageID=XXXついてしまうからだ。ちなみにmod_rewriteでは以下のURLでアクセスできるようにしてある。
/(モジュール名)/(アクション名)/

でPagerを使う場合は、Pagerに渡すオプションの値を以下のように設定した。
$pagerOptions[‘append’]=false;
$pagerOptions[‘path’]=SCRIPT_PATH . $controller->getCurrentModule() . ‘/’ . $controller->getCurrentAction() . ‘/page/';
$pagerOptions[‘fileName’]=”%d”;

‘append’のところをfalseに設定し、これでQUERY_STRINGでpageの自動付加を抑制。
‘path’と’fileName’の区切り方はまたおいおい勉強するとして、”%d”と書いてあるところがミソ。ここにページ番号が入ってくれる。
現在諸々上記の内容で開発中。すごく快適!。

キャッシュして軽いページを(Cache_Lite)

2007/01/13 | その他PEAR全般

これも秋元氏の書籍に誘発されてチャレンジした。元来処理内容をキャッシュするなんて、よほどのアクセス数でもない限り必要がなかったわけだが(アクセス数がないとサーバに負荷がかからないから)、マッシュアップしたサービスを作成する際は、相手のサーバのことも気にしなくてはいけない(利用規約に制限事項もあるかもしれない)。ということで、データをキャッシュ。これもPEARを利用すれば簡単。

<?php
 require_once(‘Cache/Lite.php’);
 $cacheOption=array();
 $cacheOption[‘cacheDir’]=’./cache/';
 $cacheOption[‘lifeTime’]=1*24*60*60;
 $myCache=new Cache_Lite($cacheOption);
 if(!$cachedData=$myCache->get($cacheId)){
  //キャッシュにヒットしなかったら
 }else{
  //キャッシュにヒットしたら
 }
?>

ファイルを読み込んで、コンストラクタの引数にオプションを与える。オプションはキャッシュデ使用するディレクトリとか有効期限とか。キャッシュしたい内容は、IDごとに管理し、ID自体は自由に設定できる。
つまりなんでもキャッシュしておけるので、バイナリデータ(例えば画像とか)でもデータベースから取り出したデータでもOK。

簡単だから諸々の場合に応用できる。これも使えるライブラリだ。

結論は問題なし(Pager_Wrapper読んでみた)

2007/01/10 | その他PEAR全般

Pager_Wrapperはダメかも・・・、とソースをちら読みして思ったけど、少し時間をとって読んでみた。結論は「問題なし!」。
動作としては以下のような感じになっている。

■与えられたSQLとPagerのオプションから、データ件数を取得するSQLを生成
■データ件数とPagerオプションから、SQLのLIMIT句部分の値を生成
■データ取得の際には、実際に使用するデータだけを呼び出して変数に格納(ここでqueryAll)

ということで今まで自前でやっていた処理を、すべてまかなっていることが判明。これで何の心配もなくPager_Wrapperを使える!。コメントをいただけたので、なおのことソースを読み返したのだが、結局はそれがよかった。
これでまた少し楽ができるようになる。

やっぱりちょっと・・・Pager_Wrapper、Pager

2007/01/09 | その他PEAR全般

Pager_Wrapper、やっぱりだめかもしれない。
基本的にクラスとかファンクションとかで提供される、各種便利ライブラリ(PEAR含む)のソースは読まないようにしているのだが(ソースを読む時間があるのなら、ソースを書くほうがお金になるから)、ちょっとだけ気になったので、読んでみた。
んで、結論。
内部でqueryAllしてた。

これってウェブサーバとデータベースサーバが別サーバだった場合、大量のデータだったら問題にならないのだろうか。と、それよりも以前に(同じサーバだったとしても)100万件くらいのデータだったらメモリ的にまずくないのか・・・(まぁそうならないよう考慮すべきなのかもしれないけれど)。
データの件数によって使い分ける必要があると感じた。

ミッションクリティカルなときは使えないかも、Wrapper_Pager、そしてPager。


守谷市(まちの情報ポータル) 無料アンケートレンタルjpForm.net