アーカイブ: 投稿

iPodのバッテリが劣化してすぐに切れてしまうので使わなくなってた。
最近PSPでAAC（iPodの標準音楽フォーマット）のファイルを再生出来る事を発見。
PSPで音楽聴いてる。
新しい曲は知らないので、古い曲しか聴いてない。Dragon Ashとか。
それまでって歌と言えばラブソングとかそういうのばっかりだったけれど、Dragon Ashって親にマジ感謝とかって歌詞にし始めて、当時非常に斬新に感じたものです。

先日コーヒーショップにいると、隣の席にグループがいて、どうやら就職活動してる女子学生とOBの商社社員2人という事らしい。
その商社に入社できるように、エントリーシートや面接の話し方について指導されてた。
話し方がイライラさせるとか、とにかく全部ダメって感じで。
きっと御説ごもっともなんだろう。
自分だったら耐えられない状況だなと思った。
で、幸運な事に自分の職業は自営業なわけですが、先日やっと確定申告が終わった。
今年こそ早めに取りかかろうと思っても、いつもギリギリになってしまう。
この感じ、小学生の頃の夏休みの宿題に似てる。

自分は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を思いつくと喜びがある＞
だとか。
結局、自分にとっては最後のが一番大きな理由かも知れません。