おはどん
会社がトリプルモニターでリモート繋げるのはいいがこっちは2枚しかないから画面足りねえ…
やっぱタブレットを予備ディスプレイにするか
https://www.risewill.co.jp/blog/archives/3483
どれが一番効率いいんだろうなあ…
あとwhere句に絡めずinner join句も絡めたいとすると
とかもあるし
長めのSQLの結構の数をjoinするとなるとEXISTSはあまりいただけるものでもないよなあ…
https://qiita.com/tatsuo-iriyama/items/83b12d066453f8478fd7
実行計画調査してもいいがめんどいというか
そもそも論としてソースに書かれているSQLの効率が非常に悪いから調査するまでもないしスルーしようと思ってる
だからなんで「一覧」を一回SQLから戻ってきてListに持たせてListをforしてまた要素をSQLにかけてるんだよ！
ってところが非常に悪い
from
aTable
inner join bTable
on aTable.id = bTable.id
and bTable.type_id=4
and aTable.tel_type=2
;
みたいなことを平気でやる
innerjoinのon句をWhere句代わり使うのは
joinするテーブル数が増えたときとかレコード数が多くなると影響がデカい
全部joinしてからWHEREするか、
条件に合ったレコードをjoin時に切り落とすか。
今回のプロジェクトで我の書いたSQL≒JOOQコードはWHERE句が極端に少ない
AClass hoge = new AClass()
hoge = fugafuga.method();
ってソースコードマジでやめてくれーーーーー
コーダーによってバグの傾向はあるな
まあ基本的に動作確認なしで単体に回ってくることもあるし（ぬるぽ
だからといって
テスト駆動開発も悪くないんだがテストデータ作成が大変なことになるからなあ…
今回のプロジェクトでDBのデータ構造に対して割とみんな理解ができてるなあと思うのはDBのサンプルデータが結構しっかり作れたところだろうか…
