ロジックをDBMS側に寄せるデザインパターン

O/Rマッパー（ORM）かSQLか、という話が一部で盛り上がっていたので追いかけていました。

ORMについては以下のような見方をすることもできます。
「最初からあらゆる要素をオブジェクト指向で設計、実装すると決めた新規開発システムならばORMは有力な採用候補」
「非オブジェクト指向で設計、実装されたシステムにORMはあまり向いていない」
なので、すでに存在しているデータベース上で別の新しいシステムを構築するような場合は、ORMはあまり向いていないと思います。


O/Rマッピングツールに対する誤解をときたい - ITは芸術だ

引用したエントリはとても冷静にORMの利点を説明している良記事です。
この記事の内容には全面的に賛同しつつ、自分としてはSQL側からちょっと書いてみたいと思います。
　
以前、試しにクエリに付随するロジックをできるだけDMBS側（SQL）に寄せるようにして開発したことがあります。扱うデータは顧客名とか支払金額とか消費税といった典型的な業務システムです。多数のテーブルからデータを取得し集計する処理だけでなく、3桁ごとのカンマ挿入や、0/1のIDを税抜/税込という文字列に変換するような表示用の整形もSQLの中でおこないました。
　
結果どうだったかというと、データ操作が速いのはもちろんですが、アプリ側のソースコードがすっきりしてすごくメンテしやすい構造になりました。MVCのVの部分はビューというよりもスキンというべき薄さで、クエリから返された配列そのままをグリッドビューに流し込むだけです。Cの部分も当然薄く、ひとつのイベントに対して右から左へ渡すだけような10行以内の処理です。それ以外にビジネスロジック層を設けて逐次的な処理を書きましたが、これもデータの整形や検索前後処理の余計なロジックが入り込まないので、本質的な計算処理だけきれいに表現することができました。
もちろんその分SQLは複雑になるため、システムの規模やチームメンバーのスキルによってはデメリットの方が大きいので一般化はできませんが、こんな例もあるということです。
　
まったく逆のケースも経験したことがあります。とある国内最大手のSIerのプロジェクトに参加したときはストアドプロシージャが禁止でした。これはこれで無理もなくて、何年も運用続けている古い設計の大規模システムで、単価の安い協力会社から来る低スキルエンジニアを多く使うチーム編成だったのがひとつの理由です。ソースコード管理もいまいち洗練されておらず、ストアドプロシージャのソースコードのバージョンを管理しきれないリスクもありました。実行速度については、複雑でメンテしづらいストアドを書いて速度向上を図るくらいなら高速なハードウェアを用意する、という富豪的な発想があったように思います。
　
ところで、ORMとSQLとはそもそも比較できるような同じレイヤにはないことはちょっと考えれば分かります。比較すべきは、クエリに付随するロジックをアプリネイティブ言語で書くか、DBMSネイティブ言語で書くか、ということだと思います。
　
SQLは、慣れていないプログラマーにはとても違和感がある言語で扱いづらいのもわかります。また、COBOLやJCLなどIBM汎用機の流れを汲む言語の特徴である、自然言語的なシンタックスや大文字表記というあたりも実態以上に古臭く見えてしまいます。そのため最近の洗練された軽量言語で記述できるORMと較べると見劣りするかもしれません。ただこれはSQLのシンタックスがいまいちなだけであって、DBMSネイティブ言語という考えが悪いわけではありません。
当面の間SQLは（特に業務システムでは）スタンダードであり続けるでしょうが、将来SQLと同じようにリレーションの表現や集合演算に特化して、より直感的でデバッグしやすいDBMSネイティブ言語が出てくればこういった不当に低い評価も見直されてくるのではないかと思います。