カテゴリー: サーバ管理・プログラミング

先週、うちで使ってたルーター（NECのAterm WR4500N）が突然壊れて、半年くらいぶりに秋葉原まで行ってルーターを買ってきた。
この際なので、Windows7も買って、メインマシンをVistaから7にした。
7を使ってみて、Vistaと大差ないと思ったけれど、コントロールパネルのデバイスとプリンターの表示が分かりやすくなった事とUACで権限昇格する回数が減った事は良くなったと思った。
64ビット版にしたけれど、手持ちのプリンターや周辺機器は問題なく認識した。よく使うアプリケーションを一通りインストールしたけれど、普通に動いてる。
メモリが搭載している通りに4GB認識するようになって良かった。32ビットのVistaでは3.3GBしか認識してなかった。

メインマシンのOS移行は面倒で、丸1日くらい潰れた。
新しいルーターにMacBook　Proが無線でつながらない問題もあり、大変だった。
（調べて分かったけれど、Macを11nでつなげようとするとトラブルがかなりあるようだ。結局、フルスピードでの接続は無理で、チャンネル幅を下げる事で安定して接続するようになった。WindowsPCでは問題ない。）

ちなみに、外人はルーターをラウターと発音する。昔、仕事先にアメリカ人学生がバイトで来てて、ラウターって言ってた。

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