■

データの結びつけを考える。
検索の効率を考える。
プログラミングの精度と効率とメンテナンスを考える。

正規化の話はよく出るが、し過ぎず、しなさ過ぎずが一番。
「しなきゃいけない」「やらなきゃならない」ってな強迫観念にかられた理由から
とられた形式は得てして失敗の道を歩む。

ここ最近ずっとやってることがある。
全てのﾃｰﾌﾞﾙにはユニークIDをつけること。
一覧検索以外の、1件検索は全てﾕﾆｰｸIDで検索できるのが魅力。
検索用の画面に必要なソースコードがこの準備だけでえれぇ簡略化できる。

データベースによってはもともと持ってたりする。
Oracleにはrowidが、PostgreSQLにはoidが。
SQLServerやMySQLでも無いなら無いで足せばいいだけ。

やってみて思うこの感触。
一覧検索画面→詳細表示画面の連携はよく見る形式。
そこのソースコードが画一化できるメリットは決して少なくない。
アホなDB設計をやってもーていても、一覧検索時にユニークKey一つで、
同じレコードの再検索ミスが無くなるのだから。

ってことをやりながらちょっぴり
「さすがオレやな( ´∀｀)ﾑﾌ」っと軽く自己陶酔を楽しんだ後、我に返る。

データベースの設計でこんなことって言わなくね？
「素人でもわかるDB設計」なんて本の中には正規化は書かれていても
プログラミングが難しくなるとかこれならいけるとかいう本無くね？
検索速度が落ちるなら予め検索用テーブル用意しておくとか、
そーゆー発想をザックリ語ってるのってあるのかな。
一見まともそうな論理にだまされて、
余計なロジックに自らハマりこんでいってるんじゃないかなーなんて思った。