テーブル設計

クリスマスなのでたまには技術ネタ
元になる情報を集めたりしてデータの関連とその構造と項目とか型とかを決めましょう
っていうのが旧来から続くテーブル設計の基本的な流れ
扱い易さとか考えると正規化って要るよね〜って話になるし、その元になる情報ってどうやって集めるの？手順は？って話からいろんな方法論が出てくる

それらのほとんどの方法論がほぼ無視してるのがフラグの話
フラグの話は一部の方法論がこういう風にフラグを作ると良いかも〜って言う程度であんまり扱われない
手法の中心はテーブル設計であってフラグ設計じゃないからね

デザインパターンが日本で知られるきっかけの本ですらStateパターンがあるくらいだから状態の管理って言うのはごく普通の事
プログラムのIFが増えるのも、画面を跨ぐ様なバグが出るのも、修正が面倒になるのも、集計が面倒になるのも、大抵はこの状態の扱いが原因

フラグの設計と状態の管理は実は同じって言う事でテーブル設計にStateパターンを持ち込んだのが現S2Buriの元のアイデア
基本的には状態と状態の前後関係だけを管理するのが主目的でそれ以外はおまけみたいな感じ

テーブル設計にStateパターンを持ち込むと一番変わるのが実はテーブル設計そのもの。
テーブル設計が簡単になる＝テーブル設計に高度な技術は不要とまで言い切れる状態が作れる
まぁちょっとしたコツはあるけど、それも正規化さえ理解してれば良いくらいの話
結果的にテーブル設計よりもどんな情報をどう集めてくれば良いのかだけ考える事になった

じゃあどんな情報を集めるのか？ってのがポイントになる
キーワードは伝票
伝票はたとえばAmazonで注文したときについてくる１枚物の紙だったり、レシートだったり、居酒屋で注文するときの情報だったり・・・
ほんとにそこらに転がってるものはかなりの割合で伝票になる

伝票から簡単にテーブル設計をして、必要な伝票を追加したりして
伝票の項目ごとにエラーのチェック方法を考えたりして
ついでに状態遷移を考えて、それぞれの状態で追加・編集するものを指定して
状態ごとにやる事を考えると
必要最小限のサービスの設計が完成する
あとはこのノリでたくさんの伝票を設計と伝票間の連携を考えればすべて完了！
このくらいなので、業務システムのサービスレベルの設計はすっごい簡単www
ポイントがあるとすれば、画面に表示する項目は状態と重複しても気にせずに伝票の項目として持つって事かな〜

昔作ってたBurixってのはこの考え方で自動化できるところを徹底的に自動化したもの。
まぁ決める事さえ決めればあとは自動生成ってことなんだけどね〜