たちあがれ義理人情プログラマ

USP Labの當仲さんのキーノートセッション。當仲さんの個人的な経歴から、ユニケージ開発手法にたどり着くまで、そして経営哲学的なお話をされていた。私はデータベースの関係の人でもあるので、ユニケージ開発手法に関して、感想を述べたい。
ユニケージ開発手法とはwikipediaにもあるが、データベースを使わず、テキストファイルベースでスクリプト言語の小さなプログラムをパイプでつなぎ合わせることにより開発する手法である。非常に低水準(OSに近い)であるため、速度が出るし、短いスクリプトで記述できるため、圧倒的な開発生産性が得られるという。
たとえば、データベースを使った場合は、ちょっと考えただけでも、以下のことが行われる。

  1. SQLをサーバーのディスパッチャプロセスに投げる
  2. ディスパッチャは空いているサーバープロセスを捕まえて、SQLをおくる
  3. サーバプロセスはSQLを構文的に解釈し、構文木をつくる
  4. データ辞書と突き合わせ、テーブルやカラムの存在などを確認する
  5. 検索条件、データの散らばり具合から最適な実行計画を求める
  6. 実行計画に従い、対象のオブジェクトのデータブロックについて、メモリ上のバッファをチェックする
  7. 存在しない場合は、ハードディスク上のデータブロックを読み込む
  8. メモリ上のバッファが一杯の場合は、メモリ上に消すべきデータブロックを探し出し、該当データブロックがすでに更新されている場合はハードディスクに書き込む
  9. 読み込むデータが入っているデータブロックをメモリ上に読み込む
  10. 必要なデータを抽出し、クライアントのプロセスに返す

検索を考えただけでも、データベースは多くの仕事をやっている。更新系となるとさらにステップが増える。ではどうしてこんなことをやっているのだろうか?要因としては「多くのユーザからの様々な問い合わせ・更新処理に対応するため」である。ユーザからはどんな問い合わせ(SQL)がくるかわからない。また、多くのユーザから問い合わせがあった場合でも一貫性をもって検索・更新を行えるようにするためである。
逆に言えば、定型的な業務や、一括処理については、データベースはかえって無駄が多いといえる。一例を挙げるとすれば、一括処理でエラーが起こった場合のトランザクション制御はどこまで必要だろうか?結局、大量データを更新・追加・削除するために、処理の途中でコミットを入れているとすれば、もはやトランザクション制御は意味がない。
もう少し考えてみる。SQLはデータアクセスの内容を指示しない。何がほしいかだけを示すだけである。データベースシステムがそのほしい内容に従って、最適な実行計画を策定し、それに従ってデータにアクセスする。これは、データの物理的な格納形態を意識することなく、処理できるといういい面を持っている。しかし、定型的な業務(問い合わせ)におけるレスポンスが出ないなどがあった場合、結局何をやっているかというと、その定型的なSQLがどのように処理されているのか、実行計画を見て、チューニングをかけている。間接的な処理が増えることによって、かえって面倒なことになっている。
ユニケージ開発手法というものの細かい部分までは、この発表ではなんとなくしかわからなかった。ただ、當仲さんがダイエーなど流通業における業務を完全に理解し、何が求められているのかということを把握していたからこそ、無駄なDBの機能に気づくことができ、必要な機能に絞り込んだ結果、たどり着いた結論がユニケージ開発手法なのだろう。
私は、このような手法を適用するとするならば、一括処理で、検索はその一括処理で生成された結果だけを用いるような業務に使いたい。今回作っている原価計算はまさに最適だったのではないかと思った。