■

シンプルな実装は速度も速い。
これを心がけてから物事を見ると今まで見えなかった方向が見えてくる。
シンプルな実装になれないものは何かがおかしいのだ。

あるところでこんなようなSQL文をみた。

(　Select　a.hoge, ・・・（省略）・・・
　 from　　tableA a
　 where　　a.hoge = ・・・（省略）・・・
)
union
(　Select　b.hoge, ・・・（省略）・・・
　 from　　tableb b
　 where　　b.hoge = ・・・（省略）・・・
)
union
(　Select　c.hoge, ・・・（省略）・・・
　 from　　tableC c
　 where　　c.hoge = ・・・（省略）・・・
)
union
(　Select　d.hoge, ・・・（省略）・・・
　 from　　tableD d
　 where　　d.hoge = ・・・（省略）・・・
)

おれ：( ´∀｀)＜これなにしてるの？
担当：(..゜Д゜)＜月次のデータを表示するためにやってます。
おれ：( ´∀｀)＜日次データの反映とかリアルタイムに見れなきゃいかんもんなん？
担当：(..゜Д゜)＜さ〜。

10中8,9そんな要件いりません。
月次処理という言葉を用いている以上、月に１回行われるのが原則です。
月に１回でおさまらない月次処理ってありえんでしょ。

あからさまに遅いSQL文な上に、メンテナンスもしにくい。
DBのリソースも大量に消費してくれるおまけ付きですよこれ。

物事は１つ１つケリをつけるほうが一挙にやってしまうよりも安全確実な上に、
実行速度も速いことがあります。
大量のunionが使われている場合はその典型的な例です。

( ´∀｀)＜新規テーブルつくったら？
(..゜Д゜)＜え？何でですか？
( ´∀｀)＜月次集計データ保存用のテーブル。
　　　　　　　そこにデータをいれといて、画面からはそこから取り出すと。
　　　　　　　そーしといたらプログラムは楽チン。速度も期待できる。
　　　　　　　項目の修正変更があったときでも変更に強いぞ。修正個所がわかりやすいからの。
(..゜Д゜)＜おお。
( ´∀｀)＜集計開始用のイベントは別途必要になるけどな。
(..゜Д゜)＜それどうですかね？お客さん的に。
( ´∀｀)＜そこを納得させるように持っていくのが技術職の説得力の見せ所ですがな。

納得さえしてもーたら運用時にも開発時にも楽ができる。
双方の得になる。
開発者だけが楽をできるって仕様変更には賛成しかねるが、
この場合は多少無理を言っても説得する価値はある。

(..゜Д゜)＜でも今更仕様変更できますかね？
( ´∀｀)＜そりゃ現状がどーなってるかしらんが、状況が許すならやるよろし。

と言ったところで、同じ仕事をしていなければ変更なんざされるわけがありません。
何はともあれ動くところまで作ったものには愛着があるのです。
それを破棄するのはどれほどのことかはわからんでもないし。ヽ(´ー`)ノ

( ´∀｀)＜SQLを見て仕様状況確認をちょろっとした結果。
　　　　　　以上の理由によりへたれ仕様と認定しますた。
　　　　　　以後また同じような状況が出てきたら気をつけるように。
(..゜Д゜)＜わかりました〜ってへたれ仕様とは言いますね。
( ´∀｀)＜最近複雑なSQLになるようなことってないもん。
　　　　　　仕様がおかしければ仕様から正すし、
　　　　　　テーブル構造がおかしければ、テーブル構成も正すし。
　　　　　　そっちのほうが結果的にスリムなシステム作りができるものなのよ。
(..゜Д゜)＜ふむぅ。
( ´∀｀)＜なので、そういうおかしさを正すことについて、
　　　　　　努力の跡が見えないのならばおかしさにも気づいてないことになるやん。
　　　　　　これ見えへんやん。
　　　　　　気づけないのなら技術者としての力量がしれるやん。
　　　　　　知れたやつの設計なら完璧であるとは思われへんやん。
　　　　　　なので、へたれ扱いしてみた。うひっ。
(..゜Д゜)＜これ○○さんに言われてたんですが。
( ´∀｀)＜○○さんは経営手腕とかすごいけど、システム開発については並以下やで。
(；゜Д゜)＜うわぉ。
( ´∀｀)＜人数少ないけど分業分業。
　　　　　　○○さんはマネジメント、おれ開発。きみこれから。
　　　　　　役割分担役割分担。
( ´∀｀)＜っつかうちでやってるやつやったのねこれ。
(..゜Д゜)＜はい。
(#゜Д゜)＜なら直せすぐ直せっ！！

便利な命令は使うと楽ができそうだけれども、
決して楽にはなれない痛し痒しなものもあるってことですな。(´ー｀)┌フッ

最近本から覚えた言葉。
　プログラムの「中で」ではなくプログラムの「中へ」