ノリックのIT生産性向上、ライフハック、プロマネのお仕事備忘録

IT系の仕事の事とか役立つツールとかプロジェクトマネジメントの事とかを記載していきます。

RDBの正しい歩き方を読んで(システム屋の立場から)

blog.suganoo.net

 

 

購読しているsuganooさんのブログ見てて興味を惹かれたので読んでみた。同意できるところもあったし、自分とは意見も違うところが有るし、「あのアンチパターンはないの?」と思うところがあった。システム屋の立場からとしたのは自社サービスのシステムと、SI業者として開発する場合で取る方策は違うかもしれないなと思ったからである。まあ、金と時間の問題なのだが。
 最近はゼロベースで新規システムを作るということは殆ど無い。既存システムの改修案件しかない。つまりアンチパターンがすでに組み込まれた状態のシステムに向き合う必要がある。自分だったらどうするかなと思いながらこの本を読んだ。PostgreSQL、MySQLを前提にかかれているが、自分はPostgreSQL、MySQLは使ったことがないのでちょっと勘違いもあるかもだが、ご指摘いただければ幸いである。
 

1. 正確な名前をつけろ(完全同意)

 これはには自分もずいぶん悩まされた。例えば「削除フラグ」。
本文中でも書かれているが、スペルミスぐらいだったらまだいいよ。DeleetFlagとか。でもね、曖昧な意味だからこれがテーブルとかサブシステムによって違う意味で定義されてしまっていることが有る。
・削除フラグ=1:削除済み (これがまあ普通だろう)
・削除フラグ=1:削除対象 (バッチ処理でこれから処理する対象として使ってるケース)
・削除フラグ=0:削除済み (削除フラグの名前が曖昧だから、誤った解釈をする人がいる)
・削除フラグ='01':削除済み(データ型を文字にしてしまっているケース) 
 
まずは名前の定義として「削除済フラグ」にしてほしい。自分が設計する時に心がけているのは論理名でフラグを付ける時に曖昧な解釈にならないことに気をつけている。
 

2. 外部キー制約をつけろ(ドロー)

 不思議な事に今まで担当してきたシステムで外部キー制約をつけているシステムを殆ど見たことがない。Accessで自分が作ったシステムには外部キー制約をつけた記憶があるぐらいか。本の後半でふれられているけど外部キー制約をつけると単体テストがやりづらくなるという問題のせいかな。
 そのせいでRDBからリバース・エンジニアリングする時にEntityの関係は気合で調べなければならなくなる。私が愛用しているA5M2に備えているERDを作成する機能を使用しないもの外部キー制約を使用しているシステムが殆どないから。
 既存システムの改修案件だったら新規に追加した項目に外部キー制約をつけると、本番環境にリリースした時に実はマスタと不整合なデータが有りましたなんて事になりかねないのでつけないか。
 

3. 効かないインデックス(B Treeインデックスにしか言及しなかったのは反対)

前半の方で削除フラグをテーブルに持つのではなくて別テーブルにしろと書かれていた。状態によってテーブルを分けるべきだということだが、これもやりすぎるとどうかと思う。論理削除したデータを全部別テーブルにしろということになるとテーブルの数は倍になる。論理削除したデータでも過去データは照会したいという要求もあるだろうからテーブルを分けているとプログラムが複雑になる。カーディナリティが低い列にはビットマップインデックス貼ることに言及しても良かったのではと思ったが、作者の意図があったのだろうと思う。結局最後のほうに書かれているがやりすぎは禁物ということだがそのバランスは難しい。一回限りの案件だったら削除フラグつけてしまったほうが工数は少なく対応できる気がする。(そういう対応が積み重なってトンデモなシステムになるのだろうが)
 

4. フラグ、ステート、タイプにNULLを許容する(個人的アンチパターン)

以前やったプロジェクトでC++からJAVAにコンバートする案件で地獄をみた。テーブルにNOT NULL制約が全くついていないシステムだったから怪しいとは思ったんだが、フラグなのに0(ゼロ)、1、NULLがあるの。NULLってどういう時に入っているんですか?ってお客様のシステム担当に聞いても、設計書を見てもわからない。結局、そのカラムを参照するときは「もしNULLだったら~」というロジックを書かざるを得なくなる。その時の設計をどうするか考えないといけないし。ヌルポ案件の暗黒史として自分の心に深く刻まれているから、誰かがフラグやタイプのカラムを追加しているのにNOT NULLとデフォルト値つけていなかったらすぐ突っ込む。
 

5. 番号なのに文字列で定義(個人的アンチパターン)

 シーケンスで連番をふっている主キーとか社員番号で数字しか無いのに文字列で定義して、しかも先頭0埋めしているケース。もうね、毎回0埋めして比較、更新しないといけないし害しかない。番号しか無いなら数字にしてって思うけど、既存システムなら黙って従うしか無いのが辛いところ。
 
まだ思うところはあるけど切りないからこのへんで。
 
まともなテーブル名や変数名になっていないシステムの辞書をつくってサクッと検索するためのツールを考えました。もしよかったら御覧ください。