例えば、Hibernateでね

TableAとTableBがmany-to-oneの関連を作ろうとして、結合条件となるcolumnが2つ以上あった場合、つまりOne側の主キーがcomp_idとかの場合にjoin対象のカラムの値をTableAから取得したい場合、

tableA.getTableB().getComp_id().getJoinColumnA()

になっちゃう。SQLなら

TableA.JoinColumnA

いや別にね、このコードを書くこと自体は新人丸出しの人間でも書けるでしょうよ。そのときはいいの。分かってるもん仕様もはっきり。やるべきことも。のりのりで書くことでしょうよ。ただ、こんなコードがあちこちに書かれていって出来上がったシステムって? どう? 


例えば何年か後このシステムを知らない人間が保守しなくてはならなくなったとしたとき。いや、のりのりで実装してた本人だって、半年後には「あ?」とか言って、自分のコードの前で立ち尽くすはず。立ち尽くして振り返り改善するのがプロ。そこを顧みもせずに続けてしまう人間。これが恥。失敗は誰だってする。はじめは誰だって分からない。できないことがだめなのでは断じてない。何度も出来ないのがだめなのだ。学ばない人間がだめなのだ。


そりゃcomp_idを回避するようにデータ設計からできればいいけれど。そうではなくてどうしたってこういうDB使わなくてはならない場面だってあるでしょう。そのときにHibernateじゃないなっていう判断。それは経験。そして血肉化したものを教えて継承していくこと。かつての書いてしまった新人もそう唱えるようになるでしょう。それが開発チームとしての成熟につながる。あたりまえのことを考えていきたい。やってみてだめと言え。やらないでだめというオマエガダメダ!自戒こめ。