« postgresql.logの有効活用 | トップページ | デスクトップの潤い »

2015.02.20

フラグはbooleanで頼みます

先日隣の課でお守りしているシステムで発生したトラブル。
「フラグの値がブランクになってしまって予期せぬエラーが起きました!」

カラムの定義: hoge_flag char(1) NOT NULL DEFAULT '0'

………… (  ゚ ▽ ゚ ;)エッ

いやしくも「フラグ」と名乗るカラムについてはboolean型で定義をしておいていただきたいものである。
DBMSによってはboolean型は存在しないし、boolean型で宣言しても、内部的にはintというケースもあるけども、論理上真偽型である、というのはいろいろと扱いやすいのである。(とはいえ処理系に依存する・・。*MySQLはしょっぱい)
どうしても"0/1"で処理したいならチェック制約をいれときなさい……
あとPostgreSQLではchar型を使うメリットはないからvarchar型にしとこうね、とか。

今回のトラブルは、いろんな処理を持ち回っている間にチェックの甘い画面があって、hoge_flagに空値が入ったらしい。当該システムは更新処理はミドルウェアに委任しててSQLを書いておらず、更新処理はすべてのカラムを更新という挙動をする(Hibernateのデフォルトだよね)。
その中でhoge_flagに対してうまく元の値を引き継げなくて発生した事象のようだ。

また値が"0/1"の文字列になっていたのは設計規約でそううたわれていたからだそうだ。

規約1:フラグは0=偽、1=真 として文字列で記録する
移植性の観点から設定していたのだろうか?
今回のケースはどうもホスト時代から受け継がれていた規約を流用していたらしい。

一概に全然ダメ、とはいえないけどもねえ。ちょっと考えさせられた。(実際に値が変わってなくても全カラムへの更新処理を行う処理系についてもだけど(^^;)


MySQLだとbool型で指定しても0/1以外の整数値が入るうえにCheck制約が役に立たない(!)と言うことなので、列挙型(enum)の方が安全、ということがあったりして侮れないんだけども(^^;;

|

« postgresql.logの有効活用 | トップページ | デスクトップの潤い »

コメント

コメントを書く



(ウェブ上には掲載しません)




トラックバック

この記事のトラックバックURL:
http://app.cocolog-nifty.com/t/trackback/2022/61159446

この記事へのトラックバック一覧です: フラグはbooleanで頼みます:

« postgresql.logの有効活用 | トップページ | デスクトップの潤い »