DBエンジニアとアプリエンジニアの間にて #clubdb2

#ClubDB2に行ってきた

7月13日に #ClubDB2でDBエンジニアとして有名な方がお話されるとのことだったので、
最近DBに関してまじめに考えていないなーと思い行って来ました。

普段、業務系アプリケーションエンジニアをやっている人としてはちょっとなぁと思える内容だったのでそちらについて。

DBエンジニアの責任分界点について

さて、登壇者の方が物理的なところ(ストレージ)について言及された時にDBエンジニアの責任分界点について、DBエンジニアはストレージについては責任分解が行われるため、触ることが出来ない。チューニングを行う場合はそちらも触れないと限界があるというお話をされていました。

いろいろな会社が入る以上しょうがないのですが、そもそも責任分界点という考え方はどうなんだろうー。

アプリケーションエンジニアとDBエンジニアの責任分界点について

"責任"から言えば、たぶんアプリケーションエンジニアはDBは触りたくない(触らせて貰えない)し、DBエンジニアはアプリケーションについては触りたくない(触らせて貰えない)と考えているでしょう。
会場では誰も何も言っていなかったけれども、共通認識としてアプリへの責任分界点がそこにあるということは判ってしまっていたはず。。。

しかし、チューニングなんて適切な箇所で適切なだけするのが一番良いわけで。(アプリケーションに大量にデータを取ってきてぐるぐるさせているのをDBの性能を上げることで対応しようとするのは間違っているはず)
たぶん、その"責任"がわけられた向こう側までどうやれば救えるのかという事を考えた結果、DBエンジニアがやるべきことを考えたのだろうとは思うのですが、うーんと思うのですよ。

本当は、アプリケーションエンジニアはDBの事をよく知るべきだし、DBエンジニアは動こうとしているアプリケーションのことをよく知るべきではないのかなとか。

DBFlute、iBatisのような生SQLを使用するタイプのO/Rマッパーについて

生SQLを使ったO/Rマッパーはレガシーだと思っている人間なのですが、今現在のシステム開発を考えると生SQLを使い、それを外出しすることでDBエンジニアの方にSQLの責任をもってくるというのはすごいよく出来ていると思います。
DBエンジニアのほうがアプリケーションエンジニアよりもSQLの構築に詳しい(場合が多い)のは判ることなので。
ただ、現場のニーズというより、現場を管理する側の都合により振り回されている現場を救うためという印象があってどんよりします。

テーブル変更のレポーティング機能とかも本当ならばバージョン管理システムで勝手に見てくれという気もするのですが、ああ、必要なんだな(白目)

Java Persintance APIを始めとする重厚なO/Rマッパーは日本のSIにはなじまない

実際問題JPAを始めとする重厚なO/Rマッパーを使いたがる人の一部はこれでアプリケーションエンジニアはDBを全く知らなくてもシステム構築が出来る！と思っている節があるのですが、実際にはそんなことはありません。
自分たちでSQLを実行しなくてもO/Rマッパーはオブジェクトとタプル間の変換を行なってくれますが、その後ろではSQLが動いています。そのため、エンティティ*1の扱い方によっては"ぐるぐる"と表現されていたように多数の無駄なSQLが発行されてしまい、性能的には非常に問題が出ます。*2
そういったこともあり、後ろ側でDBが動いていること、適切にテーブルにマッピングできることを考えないと非常に非効率な実装になってしまいます。
なので、O/Rマッパーを使った実装には、DBAチームが居るのならばそちらの協力が必要不可欠になります。
ただ、会場でO/Rマッパーの話題になった時にO/Rマッパー(笑)みたいなことになっていましたが、そういうことなんでしょうね。

そろそろアプリケーションエンジニアとDBエンジニアは垣根を超えるべきでは

実際問題、今後はSQLを直で叩くということは少なくなってくると思っています。GAEを始めとし、そもそもSQLが発行できないSaaS/IaaS*3もできてきて、JPA等のO/Rマッパーが主流になっていくことになるでしょう。ただ、設計上、効率の良い索引を張るためにはRDBのリレーショナル理論自体はすごい必要だと思っています。アプリケーションエンジニアはRDBの理論についてより知るべきだし、DBエンジニアはO/Rマッパーを扱えるようにある程度はプログラミングを知るべきではないでしょうか。

責任分界点とか言ってお互いに相手を関係ないものとして捉えている時代は早く終わって欲しいです。

その他、技術的な事に関する内容についてはかねがね同意できたので資料が公開されたらそちらでも。