パフォーマンスを考えるとなんとSQL in Logicが２０倍も早いらしい。そりゃそうだ。最後のアプローチは１回しかSQLを発行していないし、クライアント上のメモリでいろいろ処理することもない。この値はネットワークの回線の早さや、１顧客あたりのオーダーの数にもよる。ただ、これらを考慮しても、前二つのアプローチが最後のアプローチを上回ることは不可能だろう。
ここでは、さらに改善案を示している．しかし，SQLを結合によってひとつにしたところでフィルタリングをクライアントでやっている以上、データのやり取りの量は圧倒的に多く、追いつくはずもない。（フィルタリングをやってしまえばドメインモデルに侵食してしまう）
一方、ここではドメインモデルの優位性、つまりデータベースへのアクセス部分を書き換えるだけでよく、それ以外のビジネスルールに関する部分は変更しなくてもよいというところが示されている。
しかし，変更は簡単に行えたが，CustomerMapperはCustomerのMapperにも関わらず、Orderの表にアクセスするようになってしまった。改善前のアプローチではOrderの表についてのアクセスはOrderMapperの役割だった。それが破られている。これは、あまりきれいではない。しかし、レイヤが分けられているという部分については死守されており、ドメインモデルという観点からは正しいといえるかもしれない。
もちろん，ここではデータベースの強みを合えて強調するためのものであって、通常はこのような複雑なクエリは用いないことを考慮すべきである．また複数のユーザー環境では重たいロックがかかることがある。group byなどの集約関数を計算している間は内部的に短時間の暗黙ロックがかけられる*1。これも考慮したほうがいいということをいっている（と思う）．
