2016年04月の記事 (1/1)

ラ・ムー

仕事がはじまりました。
最初は体がついていくか不安しかなかったのですが、最初1週間を乗り切ると慣れました。
ご飯も前の晩に仕込みをすることで時短でできるようになりました。
子供達も慣れるか不安だったのですが、なんとか保育園にも慣れたようです。


伊勢市に住んでた時は安いスーパーに週末買い出しに行く時が多かったのですが、
こっちでは知らないしどうしようと思っていたら安いスーパーを見つけました。
ラ・ムー四日市店です。
何もかも安くて買うのが不安になりましたが、工場から直接大量に仕入れて大量に売る事によって
安さを出しているって店内の放送で言ってたから大丈夫だと思います!!!

ここを最初見たときに四日市市に引っ越してきた寂しさは吹き飛びました。
こんなに安いスーパーが頑張れば自転車で行ける距離にあるとか引っ越してきて良かった!!!

職場もアットホームな職場で子供に何かあっても休みやすいし、話しやすい人ばかりで
仕事がこの職場で出来て良かったなと思います。

これから頑張って働いてお金貯めるぞ
スポンサーサイト

SQLでUNION ALL

InnocentAge聴きながらかいております。
なかなか聴く時間が無いですね。
キラキラした気持ちと情熱と葛藤は懐かしいですが、色々面倒くさいのでもうしたくないなーと思ってしまいます。
同じ職場の人に「恋したい!」と言われ「え、面倒くさいよ」とつい言ってしまった枯れた大人ですんません( ꒪⌓꒪)


先日ORACLEでINNER JOINとLEFT OUTER JOINを使いました。
サブクエリサブクエリで7階層まで来たときは白目になりましたが、なんとかデータを取れました。
データ移行に伴いプログラム側(C#)で振り分けていた処理を、SQLで振り分けて取得するというものです。
SQLでサブクエリするのとかORACLEの書き方を思い出すのに1日、実際の動きやどのようなデータを取るのかの仕様確認で1日かかりました。
とりあえずやる!とかはダメですね、二度手間になりました。。。

取れた!と思ったらプログラム側では取れているのに、SQLでは取れていないデータがありました。

Atable
ID CUSTOMER DAY ・・・等々
1000 ba_gu 2016/04/25
1001 tuyorin 2016/04/26
1002 nyantyu 2016/04/26
1003 hahaha 2016/04/27

BTable
ID AtableID COUNT・・・等々
0001 1000 1
0002 1000 2
0003 1000 1
0001 1001 1
0002 1001 2
0001 1002 1

という感じでAtableBTableのIDをKEYに枝番を付けて詳細な情報が入っているTableです。
この2つはINNER JOINで繋ぎました。

この2つのTableを元にCtableDtableが作られるのですが、ちゃんと作られてなくて
振り分け条件のCOUNTを取る際にCOUNTの数が増える事態に・・・。
LEFT JOINでCtableDtableを取っていたのにBTableが1行増えているので
COUNTの数が倍になりちゃんと取れない!みたいな。。。

BTable
ID AtableID COUNT・・・等々
0001 1000 1
0002 1000 2
0002 1000 2
0003 1000 1
0001 1001 1
0002 1001 2
0001 1002 1

何故に増えている?と思ったら、CtableのデータのBTableID(0002)AtableID(1000)のデータが2件ありました。
本当は1対1で作られているはずなのにぃぃぃ!?!?
でもCOUNTの数は1つずつなので2という事は合っている。
しかしBTableのデータが2+2で4になる。
LEFT JOINの条件でBTable.ID=Ctable.BTableID ON BTable.AtableID = Ctable.BTableIDにしていたので
同じデータがあるけど1件しかないから増やそう!みたいな処理になったみたいです( Д) ゚ ゚

なのでUNION ALLで取る事になりました。
元のデータ直せばいいけど怖いよね・・・怖い。。。