各ユーザーあたり3つのテーブルを使用しています。日記本文のテーブルコメントのテーブルトラックバックのテーブル従来から、日記本文のデータの中に、その日記に付いたコメント数やトラックバック数というデータを持たせていました。データベースの正規化の立場からすると、やってはいけないことなのですが、アクセスの度にいちいちSQLで集計とってたら遅くてかなわないということで。今ではそれを逆に利用して、コメント数やトラックバック数が0のときは、そもそもコメントやトラックバックをロードするSQLを発行しないようにしています。今回、コメントの一覧やトラックバックの一覧を機能をつける際*1、コメントごとに元記事のタイトルやら日付やらを引っ張ってくるようにしました*2。元記事の「日付」と「タイトル」だけを取得するために、コメント1件につき1回SQLを発行するのはなんとも効率が悪すぎる。今回の変更で、コメントテーブル、トラックバックテーブル双方に元記事の「日付」と「タイトル」を保存するようにしました。正規化されているデータを分散させるなんて「なんてことだ!」とか言われそうですし、不整合が起こらないように管理するのが面倒ですが、背(形式美)に腹(処理速度)は代えられません。実はadiaryには、処理速度や見通しのために、プログラムの重複記述*3を敢えて行っている箇所が何カ所かあります。ルーチン化可能だけど敢えて行っていないよくみるプログラムたち1.一本道プログラム要求された処理を満たすようにだけ書かれた、能率も形式美も何もない「のっぺり」としたプログラム。いわゆる「プログラムを書ける人」の7割ぐらいが*4、こういうプログラムを書きます。2.形式美プログラム機能ごとにソースが分離され、処理はきれいなまでに抽象化され、またはクラス化(オブジェクト指向)が徹底されて、非常に美しいプログラム。ある反面、メモリの多重確保やメモリ間コピーなどは意図にも介さない。事務系のプログラムやミッションクリティカルなプログラム(たとえば銀行システムや金銭を扱うような通販システム)では能率なんて求めず安全第一で書くべきだけど、処理速度や処理効率が(極端に)求められるプログラムである場合はときとして失格*6。頭の良い人がプログラムを教科書的に学んだ際に陥りやすい。3.効率主義プログラム自分はこのタイプ。限られたリソースや有限な資源を用いて、または計算量がNPであるような大問題を効率よく求めたときなどに書くプログラム。一見するとタイプ1の「一本道プログラム」と似て映るが、きちんと眺めれば効率を求めたものか、何も考えずに書きつづったものかは一目瞭然。形式美をある程度理解した人間が書いた効率主義プログラムと、そうではない効率主義プログラムではメンテ性という意味で大きな差が出てくる。SpeedyCGI)の優先度で作成されています。