自分はORマッパーはあまり使わないです。手でSQLを書くのが好みです。
いくつか理由があります。
まず最初の理由は、
＜複雑なSQLをORマッパーの書式で表現すると可読性が落ちる＞
という事。
ORマッパーの利点としてINSERT/UPDATEが簡潔に書けるという事があります。
[code]
$member_obj = Member->create(‘name’ => ‘taro’);
$member_obj->age(18);
$member_obj->update();
[/code]
のような。
確かにINSERT/UPDATEのSQLを一から組み立てるのは面倒な作業ですが、自分の場合、PerlならSQL::Abstract、PHPなら以下のような標準関数の組み合わせでSQLを組み立てます。
[code]
// インサート文
$data = array(‘name’ => ‘taro’, age => 18);
$sql = sprintf(‘insert into member (%s) values (%s)’,
join(‘, ‘, array_keys($data)),
join(‘, ‘, array_pad(array(), sizeof($data), ‘?’))
);
// アップデート文
$data = array(‘id’ => 1, ‘name’ => ‘taro’, age => 18);
$id = $data[‘id’];
unset($data[‘id’]);
$sql = sprintf(‘update member set %s =? where id = ?’,
join(‘ = ?, ‘, array_keys($data)),
$id
);
[/code]
これでORマッパーと比べてCREATE/UPDATEの手間はそれほど変わらなくなると思います。
そして、何よりSELECTの組み立ては手でSQLを書く方が断然分かりやすいです。
ORマッパーはJOINしないで使ってる分には良いですが、自己結合や相関サブクエリなんかをやりたくなるとお手上げなので。
（仮に出来たとしても普通にSQLを書く方が簡単です。）
次の、手でSQLを書く理由は、
＜ほとんどの場合、結果セットは（オブジェクトではなく）連想配列で十分である＞
という事です。
DBから取得したデータは結局の所、HTMLの中に収まります。結果セットがオブジェクトであるメリットは多くないと考えます。
もちろん結果セットがオブジェクトならinflate出来るのはメリットだと思います。
[code]
class Member {
function sex_description {
if ($this->sex == 1) return ‘男性’;
if ($this->sex == 2) return ‘女性’;
return ‘N/A’;
}
}
[/code]
というふうに結果セットオブジェクトにメソッドを生やせるという。
ですが、
[code]
$sql = "SELECT *, CASE sex WHEN 1 THEN "男性" WHEN 2 THEN "女性" ELSE "N/A" END AS sex_description FROM member";
[/code]
というふうにすれば、連想配列をinflate出来ます。さすがにあまりに複雑すぎる事は対応が難しいですが。
また、結果セット（やクエリステートメント）がオブジェクトだとprintデバッグしづらいのはデメリットだと思います。
結果セットやSQLをprintして視認出来るカジュアルさは自分にとっては重要です。
それと、ORマッパーを導入する以上、テーブル毎のスキーマファイルなど管理しないといけないファイルが増えるのも好きじゃないです。
管理する対象は少ないに越した事はないと思います。
これら以外にSQLを手で書くのが好きなのは、
＜ORマッパーは言語・ライブラリ毎に仕様が様々でその都度覚え直しだが、SQLはほぼ標準化されており、知識が陳腐化しない＞
だとか、
＜効率の良いSQLを思いつくと喜びがある＞
だとか。
結局、自分にとっては最後のが一番大きな理由かも知れません。