おはどん
会社がトリプルモニターでリモート繋げるのはいいがこっちは2枚しかないから画面足りねえ…
やっぱタブレットを予備ディスプレイにするか
グループ内の機械リストとるのにSQL1回
機械1つにつきSQL1回
さすがにこれはないなあ…
最新値の取得方法でこんな効率の悪い取り方があったのかと他人のコードを見てびっくりしてる
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のサンプルデータが結構しっかり作れたところだろうか…
ノルマのバグ対終わったけどこれ午前中に終われたな…っていうか休み明けで十分だと思う
休出する意味ねえ
