[seasar-s2dao-dev:73] Re: Next S2Dao

[kubo]

久保です。


> > SQL一発どりのOneToManyは、テーブルに1つなら
> > まだ良いのですが、複数あると、取得するデータが
> > 膨大になってしまうのでリスクが大きい気がします。

はい。
これは確かにそうですね。
自分は「テーブルに1つ」をイメージしています。


> 必要なときに、Daoのメソッドを呼び出すでは、
> 足りないのでしょうか。

バッチならあまり問題ないとか思います。
(無論状況によりますが)

Access数の多いComsumer向けWEBサイトなどで、
１リクエストで一発SQLか、二発SQLか迷うところです。
(LazyLoadみたいに親が10件あったら10回子供取得SQL発行は論外)
ただでさえ、全く関連しないテーブルもSelect掛けないと
いけない上に、せっかく関連してるテーブルが二発SQLは
少しためらいます。

当然、関連無しで平坦に取得はできますが、その場合は、
アプリケーションがコントロールブレイク処理などで
自分で展開しなければなりません。
(SVFなどの帳票ツールなどで自動展開する機能がありますが)

自分は、

  A. DBは関連(1:n)で保存されている。
    ↓
  B. SQLでは、平坦に取得する。
    ↓
  C. 画面で関連(1:n)に展開する。※ここでは“DBと同じ持ち方の(1:n)”

というのがちょっとどうなんだろうって悩みます。
もちろん、DBでの持ち方と画面で表示する形式が必ずしも
一致するとは限らないのでVIEWがある程度編集を掛けることは
多いですが、DBの持ち方と全く同じというパターンもかなり多いです。
そのときは、SQLで取得した時点で{1:n}形式だと非常に楽になります。

ただ、確かにキリがありません。
大谷さんが仰るように「あれもこれもと夢は広がりますが、」
という感じで、どっかで線引きしないといけないですね。

そういう思想の場合はHibernateを使えとなるのでしょうか...
やはり、Next S2Dao は、「C」に関しては、
アプリ側(or 別の便利ツール)がやるものとお考えですか？

#
# もし、そういう割り切りなのであれば、「展開を簡単にするツール」に
# 力を入れていけばいいのかなって、今書きながら納得しています。
# 自分が作成してるツールで「C」の処理を自動生成するものを
# 実装中だったりしてました。
#



> ・JavaBeans(DTO)にJoinアノテーションを指定できるようにする。
> @Join("dept")
> public class EmployeeDto extends Employee {
>   private String deptName;
>   private String loc;
>   ...
> }

ちょっと技術詳細に話が変わりますが(こっちが本題!?)、

今まで、Employee側(Entityの本体)で、RELKEYなどで、
結合先がEntityで静的になってしまっていたので、
上記の仕様はかなり利便性がUPする思います。

複数のテーブルをJOINして、結合先の列を取得したい場合は、
どうイメージされていますでしょうか？
（例えば、「@Join("dept, dept2, dept3...")」とか）



-- 
_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/
kubo   <jazzflute ＠ mbn.nifty.com>
jflute <http://d.hatena.ne.jp/jflute>
株式会社ビルドシステム <http://www.buildsystem.co.jp>
_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/