こんにちは。

久々に、開発プロジェクトに携わることができ、毎日うきうきしてますよ！
今日はそんな中、プロジェクト内で出会った、ソースの書き方＋アルゴリズムの人それぞれな部分に感じたことを。

最近、自分がほんと歳をとったなぁと思うのが、若い子達とお仕事をしてる時ですね。
若い子は仕事が早い！覚えもいい！（人によるのは知ってる）
今回のプロジェクトでも、

　　　　★とても優秀な若い子に出会うことができた★

のでおじさんは満足しています。

その子のソースは読みやすい。
インデントとかそういう問題ではなく（そこも綺麗だけど）、処理のまとまりとか、
一貫性とか、華麗で端的な書き方。ほんと頭下がるおもい。

そんな中、PL/SQLあがりのおじさんは、どうしても納得のいかない部分を見つけてしまったんだよね。
ちょっと専門的な話になるのだけど、Sequelizeというnode.jsで利用するORM（オーアールマッパー）があるんだけど、こいつは残念なことにUNION、UNIONALLができません。
そこで各テーブル（MODEL）毎にデータをとってきて、JavaScript上でえいっとマージする必要がある。（処理はとても簡単）

今回はこの「UNION ALL」した結果と、トランザクションをJOINする。といった処理でした。

　・若い子
　　トランザクションを取得（オブジェクト配列へ）
　　マスタのUNIONALLを取得（オブジェクト配列へ）
　　トランザクションのオブジェクト配列をぶつける（マスタへの照合はfilterを採用）

　・MochiTomo氏
　　トランザクションとすべてのマスタを外部結合して取得（オブジェクト配列へ）
　　各マスタの中で名前がNULLでない部分を名前として再定義。

マスタとトランザクションは主キー・外部キーでぶつけるのが前提だけど、
おじさんはどうも全部とってきて、プログラムで回すというのが苦手で（苦笑）
マスタが1000件でトランザクションが1万件だったらどうしよう。みたいな。
今のサーバスペックならびくともしないのは知ってますけど。

結果としてはUNIONALLしてるのでORMにもかかわらずSQLが埋め込まれてる若い子のソースのほうが不格好です。
この辺をみて勝利を感じた（勝ち負けかい！）のだけど、結局は自己満足。

もし、厳密に処理速度を求めるならどっちよ？ってデータ要件加味してやらないかんのですがね。

ながながとありがとうございました。
このもやもやをこうやってBlogに載せてまた明日からがんばれそう（笑）