-
- いいね！0
非実在naka aki
@naka_aki_spl
再掲。SQLは、「完結したクエリ(つまりビュー)」だけじゃ部品化の粒度として大きすぎる。条件とかもを部品(名前付き部品も含む)化したい。個人的に今一番気がかりなのは「結合条件」の「部品」化。
2014-01-30 20:45:44
非実在naka aki
@naka_aki_spl
ただ、部品化といっても、特に結合条件なんてものは「任意のテーブル/サブクエリ」と好き放題に組み合わせれるハズが無い。使える組み合わせは強く拘束されるはず。、、、これって「型」じゃないのか？
2014-01-30 20:48:58
非実在naka aki
@naka_aki_spl
ある検索条件(ANDとかで複数合体するのも当然アリ)が「どのテーブル(やクエリ)を指すことができるか」は、「型」だよな。a.b=c.dなんてな条件は、テーブル粒度でいえば「aからcを」+「cからaを」指せる「型」だよなあ
2014-01-30 20:49:05
非実在naka aki
@naka_aki_spl
レゴのように何でも繋げれるというよりは、接合面の相性の良し悪しが凄く強くて、その種類の数が凄く沢山あるカンジか。
2014-01-30 20:50:26
非実在naka aki
@naka_aki_spl
あれ？型みたいに縛れるってことは、「どのテーブルとどのテーブルを結合したら間のonはどうすべきか」は「DI」みたいなもので管理できるんじゃね？
2014-01-30 20:50:29
きょん＠アジャイルコーチ、システムアーキテクト
@kyon_mm
@naka_aki_spl そういう意味だと、filterを使ったような関数っていうかんじなのではないですかね。 [うさみみ＊´×｀＊エンジニア]
2014-01-30 20:50:56
非実在naka aki
@naka_aki_spl
2つのテーブルを持ってきて、それの間での結合条件が1つしか選択肢が無いので全自動で決定する、という場合は多そう。複数有る場合もあるが「幾つ有るか実行時にならんと判らん」つまり動的型みたいな事はフツー無いんじゃね？
2014-01-30 20:51:56
非実在naka aki
@naka_aki_spl
そういやORMとかでもテーブル(クエリでもいいが以下略)とテーブルの繋ぎをメソッド(チェーン)で表現すること多いが、テーブルとテーブルの繋ぎを「繋ぎクラス」(または繋ぎインスタンス)で表現してもイイよな多分。
2014-01-30 20:55:35
非実在naka aki
@naka_aki_spl
某を思い出すんだが、繋ぎクラスってのは「AからBへ」と逆に「BからAへ」の両方の結合を統一的に扱えるクラス(オブジェクト)なんだよ。関連テーブルは正にソレだが、関連テーブルを挟まない場合も仮想的にソレが存在するかのように考えることは十分可能。
2014-01-30 20:55:38
非実在naka aki
@naka_aki_spl
(某の場合は実際に関連テーブルが無いけどAPIとしては仮想的に関連テーブルが有るかのように見えるよう細工することも可能で、そういうのは「仮想関連」とか呼んでたような気がする)
2014-01-30 20:55:40
非実在naka aki
@naka_aki_spl
SQLでJOIN書いててイライラするのの1つとして、ERモデル(かな)的には「1つの繋ぎ線」なのに、SQLではソノ線を「ドッチ向きに辿るSQLを今書いてるか」で全然様相の違うクエリ断片(結合条件とか)を書かないとならない、って辺りが。
2014-01-30 20:56:44
非実在naka aki
@naka_aki_spl
テーブル設計として、テーブル間の繋ぎ線を1本引いたとして、それを各SQLにどう反映するか？を毎回書くってのは、すげー非DRYなんだよ。書くの自体も辛いし、まして仕様変更で組み替える時の手間が爆発的に増える。
2014-01-30 21:01:18
きょん＠アジャイルコーチ、システムアーキテクト
@kyon_mm
@naka_aki_spl だとするとZipみたいなかんじか。 [うさみみ＊´×｀＊エンジニア]
2014-01-30 21:07:50
非実在naka aki
@naka_aki_spl
あとSQLって、結合とかするとき、表示するカラムを「先に」書きたいってことがしばしば有る。from t1 join t2 (selects c2_1, c2_2) on t2.hoge = t1.fuga みたいな？
2014-01-30 21:16:02
非実在naka aki
@naka_aki_spl
だって、クエリを仕様変更してて、非常によくある作業パターンとして、「テーブルとそのカラムをまとめて追加/削除したい」ってのがあって、伝統的SQLだといちいち画面を上下移動しないと作業できんのだもん。糞。
2014-01-30 21:17:00
非実在naka aki
@naka_aki_spl
ところで、検索条件をANDでくっつけて絞りを強くするのって、型っぽく考えると、継承みたいなものかなあ。制約をだんだんキツくするっていう本来ｗの意味のサブタイプねー
2014-01-30 21:18:56
非実在naka aki
@naka_aki_spl
知らんのでぐぐった [http://t.co/LV9DfK7es0 JPQL速かった！～JPAクエリ表現ごとのパフォーマンス比較 その2 - Dev3TechHack] プリコンパイルを誘発(てのか)させれば速い、ってことか。
2014-01-30 21:22:25
非実在naka aki
@naka_aki_spl
まあさっきグダグダ書いてたのって、俺としても、実行時にSQL組み立てる謂れは無い、コンパイル時とか前処理とか暖機運転の時点で済ませてくれよ、とは思ってたりする。
2014-01-30 21:22:27
非実在naka aki
@naka_aki_spl
そういやHTML生成を暖機運転しとくっていう話もしばしば有るんだっけ。じゃあSQL生成も暖機運転したいよね。
2014-01-30 21:22:30
非実在naka aki
@naka_aki_spl
JPQLとかいうのはSQLの改善版みたいな文法なのかな。するってーと、IntelliJでは普通に書けるんだよね？ね？(じゅんしんなまなざし
2014-01-30 21:24:22
非実在naka aki
@naka_aki_spl
クエリの組み立て方からハッシュ値をでっち上げて、つまり組み立て方ごとにIDぽいものを自動生成し、そのIDごとに(理想的には1回づつ)初回生成されたSQLをキャッシュし、、、とか妄想。
2014-01-30 21:38:42
非実在naka aki
@naka_aki_spl
[http://t.co/EVxldbx0BD JPQLを利用する際に行っていること - Challenge Java EE !] NetBeans良いらしい？？
2014-01-30 21:40:28