ドメインロジックとSQL - Martin Fowler's Bliki (ja)

以下の文章は、Martin Fowler による Domain Logic and SQLの日本語訳である。 データベース指向ソフトウェア開発者とメモリ上(in-memory)アプリケーションソフトウェア開発者との間のギャップは、ここ数十年、徐々に広がってきている。このギャップが原因で、データベースの機能(SQLやストアドプロシージャ)をどのように扱えばよいのかという議論が数多く巻き起こっている。ここでは、ビジネスロジックを SQL に置くべきか、それともメモリ上のコードに置くべきかといった問題について、主にパフォーマンスと更新性の観点から考察を行う。考察には簡単な例を使うが、SQL クエリはしっかりとしたもの（rich SQL queries）を用いるので悪しからず。 エンタープライズアプリケーション（訳注：以下、EA）構築に関する本（私の近著『P of EAA』など）を読むと、ロジック

[auto_chan]

むかしはデータを取って二重三重でループは嫌だループこそSQLの本懐なんだからロジックで回して下手にバグるより多少複雑でもSQLでやっちまおうデータ突っ込んでSQL投げるだけでテストも簡単じゃろ？だったが現在はプｒ

[su_zu_ki_1010]

一番下まで読むまで2003年の文章だとは思わなかった。今だとSQLのテストってどんな感じなんだろうなぁ？Twitterだとなかなか最適解が流れてこないように感じる。

[dekasasaki]

元ソースは2003年かー。(遠い目)

[uva]

Ruby on Railsのリリースが2004年。それより前の2003年に書かれたテキスト

[mano-junki]

好きな議論

[buhoho]

SQL一文で済むような処理を、メソッド何個も作って何度もDBアクセスして処理速度めちゃ遅くしてるのとかアホかと思ってた。あれドメインロジック分離なのかしら？レコードの結合くらいSQL使わせて欲しいですわ

[uunfo]

SQLおじさん、見なくなったな

[bike-a-to-z]

sparkのほうがいいんじゃないかな

[magnoliak]

異なる言語が複雑に混在するので、場合による、みたいな話に着地しがちだよねぇ

[kawasin73]

柔軟性を上げるためにビジネスロジックをあえてメモリのアプリケーション上においておくのか。転送データが大きくなるけど、パフォーマンスが課題になるときだけ SQL にビジネスロジックをいれる最適化をする。

[snowcrush]

"以前のクライアントに OO エキスパートグループがあり、彼らに会社を追い出されたことがある。私が「データモデラー」だったからだ"