複雑なクエリ(Complex Queries)

SQLは複雑な問い合わせを書くことができる。ここでは「フィルタ」や「サマリ」のリッチさをあげているが、さらにいえば複数の表を結合(ジョイン)して検索ができることもかなり強力だ。XMLネイティブのデータベースやその他のデータベースではなかなか大変である。そして、その結合した表についてフィルタやサマリをかけられるわけだ。
しかし、おそらくジョインだけであれば、とくにドメインロジックに反しないだろう(複雑なジョインは別)。Fowlerさんの例を使えば「値引き対象かどうか」というフィルタをかけてしまうことで、ビジネスロジックの内容をSQLに記述できてしまう。
DOAではSQLがデータ抽出のすべてであって、それ以外のプログラム部分でデータをフィルタしたりサマリすることは基本的に行わない。それだけSQLの記述能力はリッチなのである。

Transaction Script

手続き的にアクセスを行う方式。Fowlerさんが示している例を読むとデータベースへのアクセスはすべてfind_xxxという名前になっている。これは、たとえば「顧客IDを見つける」という処理を実行すると,引数の名前に関係付けられた顧客IDが返される.つまり一般的な関数のような処理になっている.ここで重要なことは,オブジェクトのように内部状態を持たないこと(せいぜいあって,セッションくらい).ただSQLで検索をして配列に結果を詰めているだけであり,SQLも低機能のものしか使用していないので,使い回しがきく.
ただし,この例ではテーブルごとにアクセスを行っているので非常に効率が悪い。

Domain Model

古典的なオブジェクトモデルと呼んでいるが、これは最も(オブジェクト指向的には)素直なモデルだと思う。Fowlerさんの例ではいきなりfinderというデータベースアクセスレイヤの処理から入っているが、むしろ一番最後にあるCustomerクラスにあるcuillenMonthsのようなメソッドを構築したいがために、finderがその準備をしていると考えたほうが(私には)わかりやすい。ここではfinderは単にデータベースとのアクセスのみを行っており、レイヤの分割はきれいに行われている。
ただし、やはりテーブルごとにアクセスを行っているので効率が悪い。

Logic in SQL

Havingやdistinctまで使用したSQLを使った例が示される。なんと、たったこれだけで、答えが出てくる!なんとすばらしい・・・・?(もちろん、これはFowlerさんがSQLを使うと便利な例を出しているからだろう)