フラグ・区分・コード

データベース設計といえばエンティティの設計が目立つけれど、その一方でフラグ・区分・コードの設計も重要な要素である。

フラグは2値であらわせるものということで良いのだが、区分とコードは使い分けが難しいと考える人も多いようだ。都道府県は区分なのかコードなのか、とか。ベーシックに考えれば、静的なデータが区分で動的なデータがコードなのだが、都道府県なんて変わらないと思うが、将来的に都道府県の合併がないとも言えないので都道府県はコードかなぁ、とか悩みは尽きない。

スタロジ改めマジカジャパン代表のはぶあきひろ方式では、すべてはコードであり、区分などは存在せず、状態遷移に至ってはテーブル分けやがれ、てな具合であり、ある意味わかりやすいのだが、パラダイムがシフトしまくってるので文明の衝突は不可避であろう。

はぶ方式は柔軟になることがメリットだが、エンティティの数が増加し部外者が見るとわかりにくいというデメリットが大きいように思う。従来型のデータベース設計手法がなぜひろく普及しているかと言えば、まぁありていに言って直感的であるという点が大きいだろう。

私個人としては、最近どっちつかずの立場を取るようになっており、次のような設計方針が良いのではないかと考えている。

まず、従来『区分』と呼ばれていたものを分類、性質、状態に分ける。分類とは、対象の外から与えられた情報であり、変わることが当然あり得るものを指す（例えば、集計用の商品分類など）。性質とは、対象そのものに付属する情報であり、基本的に変化しない。色や形などがそれにあたるだろう。状態とは、仮登録=>本登録=>削除などの状態のことである。なお、年齢は変化するが、誕生日に対するVIEWであると考えられるので属性と考えてよい。

まず、分類は変化することがそもそも想定されているのだから、動的な情報であり区分ではなく、マスタ化すべきである。性質は区分でよい。状態は、はぶ方式と同様にエンティティを分けるか、状態管理テーブルを作るか、状態ごとに日時型の別カラムに分けるか、のいずれかの方式を取るのがよい。個人的にはカラムで分けるのがシンプルで良いが、同じ状態を複数回通過し、その情報を保持する必要があるのであれば、状態管理テーブルを作るのがよいと思う（ただし、後者の場合はワークフローシステムの導入を検討した方がよい）。